为了帮助大家更好的学习.net,今天小编带来“.net的架构分析介绍”的相关内容,希望对大家有所帮助。
常用的架构是三层架构。
1.UITier(UserInterface,用户接口层)表示层完成向用户展示界面,提供进一步操作的“驱动接口”,例如按钮,并显示结果。
2.BusinessTier(商业层)完成数据加工,提供加工后的数据给表示层,或者数据层。又可以分为BLL(BusinessLogicLayer,商业逻辑)和DAL(DataAccessLayer,数据访问)。DAL负责存取数据,BLL负责对DAL层操作,对数据进行运算和操作。BLL也负责响应表示层的事件。
3.DataTier(数据层)完成数据存储功能。可能是
数据库、数据源、XML、文本文件等。这样就把数据、业务、显示分开了。UI层只负责显示给用户看,至于数据怎么处理运算,由BLL进行并响应,处理完的数据,怎么存取由DAL层进行,数据怎么存在介质上由Data层完成,DAL就不用管。各层之间相对比较独立,
物理依赖性就不那么高了,有时候就只需要编译改动过的层。一般对开发和
设计人员来说,只需要对UI,BLL,DAL进行设计开发,DATATier由OS或者DBMS来进行,你只需要按“格式”来存取数据即可。“三层结构的程序不是说把项目分成DAL,BLL,WebUI三个模块就叫三层了,下面几个问题在你的项目里面:1.UILayer里面只有少量(或者没有)的SQL语句或者存储过程调用,并且这些语句保证不会修改数据?2.如果把UILayer拿掉,你的项目还能在Interface/
API的层次上提供所有功能吗?3.你的DAL可以移植到其他类似环境的项目吗?
4.三个模块,可以分别运行于不同的服务器吗?如果不是所有答案都为YES,那么你的项目还不能算是严格意义上的三层程序.三层程序有一些需要约定遵守的规则:1.关键的,UI层只能作为一个外壳,不能包含任何BizLogic的处理过程2.设计时应该从BLL出发,而不是UI出发.BLL层在API上应该实现所有BizLogic,以面向对象的方式3.不管数据层是一个简单的SqlHelper也好,还是带有Mapping过的Classes也好,应该在一定的抽象程度上做到系统无关4.不管使用COM (EnterpriseService),还是Remoting,还是WebService之类的远程对象技术,不管部署的时候是不是真的分别部署到不同的服务器上,起码在设计的时候要做这样的考虑,更远的,还得考虑多台服务器通过负载均衡作集群所以考虑一个项目是不是应该应用三层/多层设计时,先得考虑下是不是真的需要?实际上大部分程序就开个WebApplication就足够了,完全没必要作的这么复杂。而多层结构,是用于解决真正复杂的项目需求的.”而且三层之间有时候也不用那么严格,得根据实际业务逻辑来判断使用。这也是软件开发所以没有一个固定流程的原因。