三层架构(转载:http://www.cnblogs.com/s021368/articles/1271159.html)

什么是3层架构?

3层架构是一种“客户端-服务器”架构,在此架构中用户接口,商业逻辑,数据保存以及数据访问被设计为独立的模块。主要有3个层面,第一层(表现层,GUI层),第二层(商业对象,商业逻辑层),第三层(数据访问层)。这些层可以单独开发,单独测试。


为什么要把程序代码分为3层。把用户接口层,商业逻辑层,数据访问层分离有许多的优点。


在快速开发中重用商业逻辑组件,我们已经在系统中实现添加,更新,删除,查找客户数据的组件。这个组件已经开发并且测试通过,我们可以在其他要保存客户数据的项目中使用这个组件。


系统比较容易迁移,商业逻辑层与数据访问层是分离的,修改数据访问层不会影响到商业逻辑层。系统如果从用SQL Server存储数据迁移到用Oracle存储数据,并不需要修改商业逻辑层组件和GUI组件


系统容易修改,假如在商业层有一个小小的修改,我们不需要在用户的机器上重装整个系统。我们只需要更新商业逻辑组件就可以了。


应用程序开发人员可以并行,独立的开发单独的层。




1.   UI   Tier(User   Interface,   用户接口层)
                  表示层完成向用户展示界面,提供进一步操作的“驱动接口”,例如按钮,并显示结果。
          2.   Business   Tier(商业层)
                  完成数据加工,提供加工后的数据给表示层,或者数据层。又可以分为   BLL(Business   Logic   Layer,   商业逻辑)和DAL(Data   Access   Layer,   数据访问)。DAL负责存取数据,BLL负责对DAL层操作,对数据进行运算和操作。BLL也负责响应表示层的事件。

          3.   Data   Tier(数据层)
                  完成数据存储功能。可能是数据库、数据源、XML、文本文件等。

这样就把   数据、业务、显示   分开了。UI层只负责显示给用户看,至于数据怎么处理运算,由BLL进行并响应,处理完的数据,怎么存取由DAL层进行,数据怎么存在介质上由Data层 完成,DAL就不用管。各层之间相对比较独立,物理依赖性就不那么高了,有时候就只需要编译改动过的层。

一般对开发和设计人员来说,只需要对UI,   BLL,   DAL   进行设计开发,DATA   Tier由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+(Enterprise   Service),   还是Remoting,   还是WebService之类的远程对象技术,   不管部署的时候是不是真的分别部署到不同的服务器上,   最起码在设计的时候要做这样的考虑,   更远的,   还得考虑多台服务器通过负载均衡作集群

所以考虑一个项目是不是应该应用三层/多层设计时,   先得考虑下是不是真的需要?   实际上大部分程序就开个WebApplication就足够了,   完全没必要作的这么复杂.   而多层结构,   是用于解决真正复杂的项目需求的.”

而且三层之间有时候也不用那么严格,得根据实际业务逻辑来判断使用。这也是软件开发所以没有一个固定流程的原因。

还有个俺收藏得
UI层:
浏览器   ——   要考虑一下不同的浏览器、和插件若干
js脚本   ——   ajax这一类的,数据验证了什么的。
显示数据   ——   放在.aspx   页面
提供数据   ——   放在.aspx.cs   页面
逻辑层:
业务逻辑   ——   承上启下,但是大多数情况只用一行代码就可以实现了。
数据逻辑   ——   组合SQL语句,存储过程的话就是给参数赋值了
数据层:
SQLHelp   ——   具有类似功能的东东
数据库里的存储过程   ——   不用存储过程的话就略掉
数据库里的视图   ——   同上,我比较喜欢用
数据库里的表   ——   基础的东东了,对于客户来说,里面的数据是最最重要的了。

  三层架构的困惑:为什么要分出数据访问层
http://community.csdn.net/Expert/TopicView.asp?id=4946236
三层架构之我见   ——   不同于一般的三层架构。也许对您会有所启发!
http://community.csdn.net/Expert/TopicView.asp?id=4949724
关于分层和架构的思考--请重视业务逻辑!
http://community.csdn.net/Expert/TopicView.asp?id=4947750
小调查,大家现有项目系统构架都是怎么样的?
http://community.csdn.net/Expert/TopicView.asp?id=4937348
请教一个架构上的问题,在某些情况下,我是不是应该抛弃ORM的思想
http://community.csdn.net/Expert/TopicView.asp?id=4947610
。NET构架之我见
http://community.csdn.net/Expert/topic/4950/4950034.xml?temp=.4981195 

转载于:https://www.cnblogs.com/msnadair/archive/2009/04/22/1441583.html

参与评论 您还未登录,请先 登录 后发表或查看评论
相关推荐

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值