三层一般分为两类:物理上的三层和逻辑上的三层架构;物理三层架构是以逻辑的三层架构为基础的,如果没有了逻辑的三层,就根本谈不上物理三层架构的部署。
什么是物理三层架构呢?
从简单了说就是每一层都分别做成一个组件,如业务逻辑组件,业务实体组件,数据访问组件等。在到复杂一些就是构建分布式系统,例如将业务逻辑层与数据访问分别部署在不同的服务器上。
我们这里讲的主要是逻辑上的三层架构。
三层基础知识
在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或称为领域层)、表示层。
那么每层都有什么作用呢,见下表:
|
作用 | 设计原则 | 常用技术 |
表示层(UI) |
向用户展现特定业务数据,采集用户的输入信息和操作 |
用户至上,兼顾简洁;不包含任何业务相关的逻辑处理 |
WindowsForm\ASP.NET |
业务逻辑层(BLL) | 从DAL中获取数据,在UI显示;从UI中获取用户指令和数据,执行业务逻辑或通过DAL写入数据源。 |
作为U层与D层的桥梁,只负责数据处理传递,不涉及SQL语句和ADO.NET |
—————————————— |
数据访问层(DAL) |
直接操作数据库,针对数据的增添、删除、修改、查找;具体为业务逻辑层或表示层提供数据服务。 |
只提供基本的数据访问,不包含任何业务逻辑处理。 |
ADO.NET+SQL语句;ORM框架;Linq To SQL |
三层结构图:
说到三层,大家是不是想知道有没有两层结构,答案是有!而且就在我们身边.以前我们的作品展,信息管理系统,第一遍机房收费,都是典型两层结构。
两层结构图:
从图中就可以看出,两层结构把界面,逻辑和数据访问统统放在了一起,互相纠缠.导致了高耦合,难复用而且当需求变更时所面临的很可能是重新开发.当然更别说后期的维护问题了。
相比于两层架构而言,三层有很多优势:
1、开发人员可以只关注整个结构中的其中某一层;
2、可以很容易的用新的实现来替换原有层次的实现;
3、可以降低层与层之间的依赖;
4、有利于标准化;
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候,极大地降低了维护成本和维护时间
当然有这么多的优势,并不意味着所有的程序都需要应用三层架构,一些简单的小程序的编写完全没必要这么复杂,而一些真正复杂的项目,三层有时候不够用,需要多层结构。
金无足赤,和设计模式一样,三层架构也有他的一些小缺点:
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本。
基础的知识就说到这,我们能不能从生活中找到三层的影子呢?
我想起了有次暑假打工的经历,那是在一家酒店做的厨师助理。呵呵,这么好听的名字,说白了就是打杂的,所做的工作就是:从仓库中帮厨师找到做某道菜需要的食材,配料等。
酒店的服务工作流程是这样的,服务员负责接待顾客,顾客通过菜单点了某些菜,服务员将顾客点的菜单提交给厨师,然后根据菜单所需,转告厨师助理去提取相应的原料,然后厨师将这些原料制作成美味的佳肴转交给服务员,服务员再将佳肴交给顾客,顾客在享用这些美味。
是不是有种很熟悉的感觉,服务员,厨师,助理 不正是很好的解释了三层架构吗?
服务员(表示层):负责前台的工作与顾客(客户)打交道。
厨师(业务逻辑层):负责具体制作某些菜(逻辑处理)
助理(数据访问):负责从仓库(数据库)中寻找某些食材配料(数据)
知识来源于生活,联系生活来学习更有助于理解。
学了设计模式和三层才知道,作品展、学生系统、第一遍机房收费系统等都是在搭鸡窝,所有的代码都放在一个个窗体里面,而且窗体间耦合还巨强,汗。。
原文地址:http://blog.csdn.net/u010028869/article/details/24711163