三层架构知识梳理

   最近学习了一下三层架构的知识,在网上搜集了一些资料,梳理了一下,以后备用,也希望能帮到其他热爱编程的人!

分层的由来:

   在学习网络的时候,书上有这么一句话:任何新技术的出现都必须具备两个条件:一是强烈的社会需求,二是前期技术的成熟!三层架构的出现,想必也顺应了这句话。

   1996年SUN公司推出了java,广受业界的喜爱,其重要的一个原因就是java专门为企业开发提供了多层分布式企业应用模型.在企业中,公司有明确的分工和部门,这些部门很可能不在同一个地区.每一个部门用到的系统一般是不同的.但是我们又希望每一个部门的信息统一起来管理,便于管理层管理.同时,企业的数据对安全性要求一般是很高的.不希望系统每一个部分都部署在每一个员工的PC上.这样显然不是安全的.所以,我们解决的办法就是把系统拆分开来,在J2EE中,应用逻辑按功能不同可以划分为不同类型的组件,各组件根据它们所在的层分布在不同的机器上,共同组成一个基于组件的分布式系统。这样,系统的安全性,可靠性大大的提高,充分发挥了分层的作用.自此,分层思想就推广开来。

   现在要谈的三层体系结构,是在客户端与数据库两层之间加入了一个“中间层”,也叫组件层,三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。这三层分别被称为:表示层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。下面具体阐述一下这三层:

 

基本的概念:

   表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。

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

   数据访问层(DAL):该层所等做事务直接操作数据库,针对数据的增添、删除、修改、查找。

各层作用:

   数据访问层:主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务.

   业务逻辑层:主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的搭建。

   表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx,如果逻辑层相当的强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。

 

引用关系:

   UI直接引用业务逻辑层(BLL)

   业务逻辑层(BLL)需要引用数据访问层(DAL)

   数据访问层(DAL)所在程序集不引用业务逻辑层(BLL)和表示层(UI)

 

说了这么多的理论,有些抽象,下面用一个形象生动的例子阐述一下:

   结合上图,把一个系统的运行,看作是一个饭点的运营,饭店将整个业务分解为三部分来完成,每一部分各负其责,服务员只管接待顾客、向厨师传递顾客的需求;厨师只管烹炒不同口味、不同特色的美食;后勤工作人员只管提供美食原料;他们三者分工合作共同为顾客提供满意的服务。在饭店为顾客提供服务期间,服务员、厨师、后勤工作人员,三者中任何一者的人员发生变化时都不会影响其他俩者的正常工作,只对变化者进行重新调整即可正常营业。

   我们用三层结构开发的软件系统于此类似,表示层只提供软件系统与用户交互的接口;业务逻辑层是表示层和数据访问层之间的桥梁,负责数据处理和传递;数据访问层只负责数据的存取工作。

三层特点:

优点:
   1.解耦。上一层只依赖于下一层,如果测试下一层没有问题,那么问题就只可能出现在本层了。便于发现和改正BUG。
   2.简化复杂问题。就比如tcp/ip协议的四层模型或OSI七层模型,各层分工明确,将一个复杂问题简化了。

   3.便于系统维护/升级。各层间通过接口解耦,接口与实现分离,从而可以非常方便的替换掉实现,或者升级实现等。
   4.逻辑复用。例如原来基于B/S开发的程序现在要改成C/S,那么只要业务层的接口没有改变,那么业务层和数据层都可以直接复用。在如,只要数据访问层接口不变,那么使用便可以有对不同数据库的实现。

   5.便于团队开发。只要各层接口在开发前规定好,那么各层可以独立开发,进化或维护。
   6.方便部署。将各层开发成组件,则可以独立部署。

缺点:
   分层过多限制了客户对系统的理解能力。Tcp/ip便将OSI七层简化为了4层。另外分层过多也增加了系统的理解难度,当然也看客户的接受能力。虽然增大了灵活性,但同时也限制了客户的理解和同客户的交流。

我们什么时候用三层呐?

   如果一个程序,业务逻辑简单,没有真正的数据存储层,就没有必要抽象出一个业务逻辑层,当具有相当多的业务逻辑,业务复杂到一定程度,而且拥有数据存储介质。我们就考虑使用三层架构了。

 

 

原文地址:https://www.cnblogs.com/lucky7/p/3768655.html