话说三层

      随着软件工程的不断进步和规范以及面向对象编程思想的应用，人们对封装、复用、扩展、移植等方面的要求，使得双层架构显得更加臃肿繁琐，三层程序架构体系应用而生。可以说，三层架构体系结构是面向对象思想发展中的必然产物。所谓三层结构，是在客户/服务之间加入了一个“中间层”，也叫组件层。它与客户层、服务器层共同构成了三层体系。这里说的三层体系，不是指物理上的三层，不是简单的放置三台机器就是三层体系结构，也不仅仅有b/s应用才有三层体系结构，三层是指逻辑上的三层。通过引入中间层，将复杂的商业逻辑从传统的双层结构应用中分离出来，并提供了可伸缩、易于访问、易于管理的方法，可以将多种应用服务分别封装部署于应用服务器，同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移植性，使用户在管理上所花费的时间最小化，从而实现了便捷、高效、安全、稳定的企业级系统应用。

     白话一点，就是随着技术的越来越成熟，人们已经不再满足一些简单的功能。人们追求完美的心理越来越膨胀。而且，现在，社会发展很快，变化层出不穷。这样，你的软件当然也不能是一成不变的，他也要应对这样或那样的变化。可是，如果，每次都从零开始的话，就有点太麻烦了吧！耗时耗力。于是，聪明的人类开始想法解决这一问题。

    首先介绍一下三层：

    界面层：从用户收集信息、将用户信息发送到业务服务层做处理、从业务服务层接收处理结果、将结构显示给用户

    业务逻辑层：从界面层接收输入、与数据层交互执行已涉及的业务、将处理结果发送到界面层

    数据处理层：数据存储、数据获取、数据维护

    在这里详细介绍一下业务逻辑层，业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上。

因此,业务逻辑层的设计显得尤为重要.既要体现到低耦合,也要考虑到高内聚的问题.我们知道类设计的时候要考虑到单一职责的原则.但这个单一职责原则,我理解要看你占到什么高度来看待的问题.单一职责不是简单的指只有一个方法,他可以理解为有一类功能.看你抽象的角度是什么.如果抽象的太具体的话,就不能很好的体现高内聚的原则.

看一个实例图

 

 

简单分析一下这个图:对于机房收费系统来说,对于卡的管理操作就是注册、充值、退卡、上机。将于每个功能相似的方法封装到一起.这样,也便于以后的维护.要是增添什么功能的话,直接找相对应的类就可以了.

面向对象的设计与分析实际上就是追求的两点：一是高内聚，一是低耦合。这也是我们软件设计所要追求的。无论是oo设计中的封装、继承、多态，还是我们的设计模式的原则和实例，都是主要为了追求这两点。而设计模式体现最多的地方我感觉还是业务逻辑层. 而我们学习设计模式,学习的是一种思想,而不是具体的解决方案.当我们遇到问题时,就可以想一下,你所遇到的问题跟哪个模式解决的问题类别是比较相似的.学习初期的话,我们就可以尝试着套用一下.

   举例说明一下:

 

 

解释:想象一个场景.一个机房,当我们进门时刷下卡,就可以开始上机.出门时,再刷下卡就下机,并计算你所花费的钱数.进门出门所触发的事件都是一样的.而且触发事件时,你并不知道应该具体应由上机类还是由下机类来处理这个问题,那我们该怎么解决呢?也许你说,直接来个判断语句,符合哪个条件就调用哪个类不就可以了.那如果,有多个方案呢,那我们的判断语句是不是比较复杂了啊.想象一下设计模式.你还记得有个模式,说的具体场景是,当我们去一个部门办事情时,我们并不清楚具体应该由什么部门的什么人来处理我们的事情.这时候,我们可以随便找一个人,我们事先定义好了,如果这个人处理不了,有谁来处理我们的事情.这样,我们就可以不用管具体应由谁来执行我们的事情了,因为我们找到这个人处理不了,他也会自动的按照我们事先定义好的顺序去寻找下一个人来执行.

这个场景是否跟我们现在遇到的场景有所相似呢?是的,理论上我们是可以用这个模式(职责链模式)来处理问题的.具体的实现方式,见时序图

 

 

设计模式体现的是一种思想，而思想是指导行为的一切，在初期,我们可能只是生硬的去套用一些模,但其间我们也会接受一种软件设计思想的熏陶和洗礼。等到设计模式的思想真正融入到我们的思想中后，我们就会不自觉地去采用设计模式的思想去设计自己的系统.

再说一下三层的特点:

优点: 从开发角度和应用角度来看，三层架构比而成架构或单层架构都有更大的优势。三层架构适合团队开发，没人可以有不同的分工，协同工作使效率倍增。开发二层或单层应用程序时，每个开发人员都应对系统有较深的了，理解，能力要求很高，开发三层应用程序时，则可以结合多方面的人才，只需少数人对系统全面了解即可，从一定程度降低了开发的难度。

三层架构可以更好的支持分布式计算环境。逻辑层的应用程序可以在多个计算机上运行，充分利用网络的计算功能。

三层架构最大的优点是它的安全性。用户只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。

当然任何事物都不是十全十美的.三层也有他自己的缺点,并不是所有的系统都适合用三层的思想来解决问题.

 “三层结构”开发模式，不适用于对执行速度要求过于苛刻的系统，例如：在线订票，在线炒股等等……它比较擅长于商业规则容易变化的系统。