三层架构-理论篇

一、概念

       设想我们去餐厅吃饭,我们刚坐下来,就会有服务员过来为我们服务。服务员记下我们点的菜,然后将菜单传给厨房的大厨。大厨拿出后勤人员事先买好准备好的菜开始烹制,然后交给服务员端出来让我们享用。其实这个餐厅的饮食服 务业务可以分解为三个部分来完成,每一部分各司其职。

服务员只管接待顾客、向厨师传递顾客的需求;

厨师只管烹炒不同口味、不同特色的美食;

后勤工作人员只管提供美食原料。他们三者分工合作共同为顾客提供满意的服务。

        在餐厅里 为顾客提供服务期间,服务员、厨师、后勤工作人员,三者中任何一个人员发生 变化时(例如请假或辞职)都不会影响其他俩者的正常工作,只对变化者进行重 新调整即可正常营业。

 

1、表现层(UI  User Interface):通俗讲就是展现给用户的界面,即用户在使用一个系统 的时候他的所见所得。位于系统的最外层(最上层),离用户最近。用于显示数据和接收用户 输入的数据,只提供软件系统与用户交互的接口界面(前提: 用户至上,兼顾简洁)。

2、业务逻辑层(BLL Business  Logic Layer):针对具体问题的操作,也可以说是对数据层的操 作,对数据业务逻辑处理。

从DAL中获取数据,以供UI显示用

从UI中获取用户指令和数据,执行业务逻辑

从UI中获取用户指令和数据,通过DAL写入数据源

 机制:

UI->BLL->UI(BLL自己处理的情况)

UI->BLL->DAL->BLL->UI(不能自己处理的)

3、数据访问层(DAL Data  Access):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找(不只可以访问数据库,还可访问XML;只要独立存在的访问介质即可访问数据库以外的数据源)。

4、实体层(Model):倾向于业务逻辑层(三层),用来封装数据,三层间传送数据,不知道各个层次,独立于三个层次,Model不引用各层次,但三个层都会引用Model。


          分层是表示将功能进行有序的分组:应用程序专用功能位于上层,跨越应用程序领域的功能位于中层,而配置环境专用功能位于低层。分层从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。子系统的分组标准包含以下几条规则可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系.


二、为什么用

       分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准 定义。

        一个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如 UI 人员只需 考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认,开发进度 就可以迅速的提高。

       松散耦合:各层都比较独立。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。

 例子:

  1、如果现在用的系统是 SQL SERVER 数据库,由于各种原因要更改用 ORACLE。如果不是三层结构系统的话,可能需要改很多代码,延长了开发周期。现在使用了三层结构,只要在加一个 Oracle 的数据访问层。这样就可以实现多数据库了。

2、现在可能要做另外一个系统了,该系统也要对数据库进行操作。如果以前编写过,这样的一个数据层。只要把以前写的那个数据层拷贝过来就可以了。实现代码复用。从 而减短了软件的开发周期了。

三、优缺点 

优点:

1、开发人员可以只关注整个结构中的其中某一层;

2、可以很容易的用新的实现来替换原有层次的实现;

3、可以降低层与层之间的依赖;

4、有利于标准化;

5、利于各层逻辑的复用。

6、扩展性强。不同层负责不同的层面,如PetShop可经过简单的配置实现Sqlserver和oracle之间的转换,当然写好了也可以实现B/S与C/S之间的转换

7、安全性高。用户端只能通过逻辑层来访问数据层,减少了入口点,把很多危险的系统功能都屏蔽了。

8、项目结构更清楚,分工更明确,有利于后期的维护和升级

缺点:

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码

3、增加了代码量,增加了工作量  

四、注意事项

    1.设计时应该从 BLL 出发, 而不是 UI 出发. UI 层只能作为一个外壳,  不能包含任何 逻辑 的处理过程 。

    2.实体层在各个层之间传递数据。

    3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。

    4.对于每一个数据库表(Table)都有一个DBEntity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。

    5.UI层和BL层禁止出现任何SQL语句。

  

 

 

 

 


  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 5
    评论
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值