三层架构分析

三层通常分为两类：物理上的三层和逻辑上的三层架构；物理三层架构是以逻辑的三层架构为基础的，假设没有了逻辑的三层。就根本谈不上物理三层架构的部署。

    什么是物理三层架构呢？

    从简单了说就是每一层都分别作成一个组件。如业务逻辑组件，业务实体组件，数据訪问组件等。在到复杂一些就是构建分布式系统，好比将业务逻辑层与数据訪问分别部署在不一样的server上。

咱们这里讲的主要是逻辑上的三层架构。

三层基础知识

在软件体系架构设计中，分层式结构是最多见，也是最重要的一种结构。

微软推荐的分层式结构通常分为三层，从下至上分别为：数据訪问层、业务逻辑层（又或称为领域层）、表示层。

那么每层都有什么做用呢。见下表：

	做用	设计原则	常用技术
表示层(UI)	向用户展示特定业务数据，採集用户的输入信息和操做	用户至上。兼顾简洁；不包括不论什么业务相关的逻辑处理	WindowsＦｏｒｍ＼ＡＳＰ.ＮＥＴ
业务逻辑层(BLL)	从ＤＡＬ中获取数据，在ＵＩ显示；从ＵＩ中获取用户指令和数据。运行业务逻辑或经过ＤＡＬ写入数据源。	做为U层与Ｄ层的桥梁，仅仅负责数据处理传递，不涉及ＳＱＬ语句和ＡＤＯ.ＮＥＴ	——————————————
数据訪问层(DAL)	直接操做数据库，针对数据的增添、删除、改动、查找；详细为业务逻辑层或表示层提供数据服务。	仅仅提供主要的数据訪问。不包括不论什么业务逻辑处理。	ＡＤＯ.ＮＥＴ＋ＳＱＬ语句；ＯＲＭ框架；Ｌｉｎｑ　Ｔｏ　ＳＱＬ

 

三层结构图：

 

    说到三层，你们是否是想知道有没有两层结构。答案是有！而且就在咱们身边．曾经咱们的做品展，信息管理系统，第一遍机房收费。都是典型两层结构。

   两层结构图：

 

          

 

从图中就可以看出，两层结构把界面。逻辑和数据訪问通通放在了一块儿，互相纠缠．致使了高耦合。难复用而且当需求变动时所面临的很是多是又一次开发．固然更别说后期的维护问题了。

 

相比于两层架构而言。三层有很是多优点：

一、开发者可以仅仅关注整个结构中的当中某一层；

二、可以很是easy的用新的实现来替换原有层次的实现；

三、可以减小层与层之间的依赖。

四、有利于标准化；

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

六、结构更加的明白

七、在后期维护的时候。极大地减小了维护成本和维护时间

 

固然有这么多的优点，并不意味着所有的程序都需要应用三层架构，一些简单的小程序的编写全然不是必需这么复杂，而一些真正复杂的项目，三层有时候不够用，需要多层结构。

 

金无足赤。和设计模式同样，三层架构也有他的一些小缺点：

一、减小了系统的性能。这是不言而喻的。假设不採用分层式结构，很是多业务可以直接造訪数据库，以此获取对应的数据，如今却必须经过中间层来完毕。

二、有时会致使级联的改动。这样的改动尤为体现在自上而下的方向。假设在表示层中需要添加一个功能，为保证其设计符合分层式结构，可能需要在对应的业务逻辑层和数据訪问层中都添加对应的代码。

三、添加了开发成本。

基础的知识就讲到这，咱们能不能从生活中找到三层的影子呢？

       我想起了有次暑假打工的经历，那是在一家酒店作的厨师助理。呵呵。这么好听的名字。说白了就是打杂的，所作的工做就是：从仓库中帮厨师找到作某道菜需要的食材。配料等。

酒店的服务工做流程是这种，服务员负责接待顾客，顾客经过菜单点了某些菜，服务员将顾客点的菜单提交给厨师。而后依据菜单所需。转告厨师助理去提取对应的原料，而后厨师将这些原料制做成美味的佳肴转交给服务员，服务员再将佳肴交给顾客。顾客在享用这些美味。

是否是有种很是熟悉的感受，服务员，厨师，助理　不正是很是好的解释了三层架构吗？

服务员（表示层）：负责前台的工做与顾客（客户）打交道。

厨师（业务逻辑层）：负责详细制做某些菜（逻辑处理）

助理（数据訪问）：负责从仓库（数据库）中寻找某些食材配料（数据）

 知识来源于生活，联系生活来学习更有助于理解。

学了设计模式和三层才知道，做品展、学生系统、第一遍机房收费系统等都是在搭鸡窝，所有的代码都放在一个个窗口里面，而且窗口间耦合还巨强，汗。。