设计模式VS三层架构

       在之前我们接触过设计模式.那么三层架构和设计模式之间到底有什么样的联系呢?

 

一.回顾设计模式

 

       设计模式遵循的设计原理为"高内聚,低耦合".设计模式的核心思想是代码的可重用性.GOR将23中设计模式分为三

 

大类,分别是:创建性,结构性和行为型..其中,创建型模式抽象了实例化过程,它们帮助一个系统独立于如何创建,组合和表

 

示它的对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化委托给另一个对象.结构型

 

模式涉及到组合类和对象以获得更大的结构,它采用继承机制来组合接口或实现,描述如何对一组对象进行组合,从而实

 

现新功能的方法.行为行为型模式不仅描述对象或类的模式,还描述它们之间的通信模式,这些模式刻化了在运行时难以

 

跟踪的复杂的控制流.

 

二.回顾三层架构.

 

       在我之前的博客<<三层架构笔记>>中曾说了一些关于三层架构的理论知识,三层架构一般可以分为两类,一种是物

 

理上的划分:客户机,应用服务端,数据库服务器.另一种是逻辑上的划分:表现层(UI),业务逻辑层(BLL),数据访问层(DAL),

 

他们之间的基本结构为:

 

(1)变现层(UI):向用户展现特定的业务数据,采集用户的输入信息和操作信息.

 

(2)业务逻辑层(BLL) 从DAL层中获取数据,以供UI层显示,从UI层获取用户指令和数据,执行业务逻辑,从UI中获取用户和

 

指令的S数据,通过DAL写入数据源..属于中间层,它的存在很重要.

 

(3)数据访问层:只提供基本的数据访问,不包含任何与业务相关的逻辑处理..

 

三.简单工厂模式回顾

 

        在我们刚接触设计的模式的时候,我们热身运动的设计模式就是简单工厂模式,简单工厂模式应该是属于创建型模

 

式,又叫静态工厂方法模式,,但是它不属于GOF设计模式之一..简单工厂模式的实质是由一个工厂类根据传入的参数，

 

动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。简单工厂UML类图为:

四，简单工厂——三层架构

 

      在实际的应用中，经常会把简单工厂和三层放到一块进行使用。简单工厂把业务逻辑和界面逻辑分开，让它

 

们之间的耦合度下降，达到可维护，可扩展，可复用和灵活性好，虽然说简单工厂把系统之间的各个子系统的耦合

 

度降下来了，但是在数据库或者是界面发生了变动的时候，还是需要花费更大的精力去修改工程，甚至是重新开发系

 

统。

 

 

      三层在简单工厂的思想和基础上，为了达到更好的可复用性，可扩展性，可维护性和灵活性，把简单工厂的

 

逻辑层进一步的分解，把逻辑层分解为逻辑判断层和数据访问层，让她们彼此直接的耦合度达到最低。不管是简单工

 

厂还是三层架构，它们之间的最终目的是解耦，最终的效果是达到“高内聚，低耦合”的效果。

 

      现在我们用一家餐馆来形容我们的系统，如果这个餐馆只有一个人，从买菜到给顾客上菜，都是这一个师傅

 

在做，那么有一天这个师傅生病了，这个餐馆就可以关门了。如果这个餐馆有两个人，有个人是专门负责上菜的，一

 

个是专门负责买菜和做菜的，如果有天有其中一人因为某种原因离开了，这个餐馆也开始勉勉强强可以维持下去，但

 

是面临关门的问题也是很有可能的，这一家餐馆就相当于简单工厂，服务员就像当于界面，服务员把客户的需求传递

 

给厨师，再把厨师返回来的成品传给顾客。不管是逻辑层还是界面层出现一点问题，还没有到这个系统立即称为垃圾

 

的地步。在如果，在一家餐馆，有三个人，一个人负责是买材料的，一个人只是负责做菜的，还有一个人是负责为客

 

户服务的，如果他们之间有一个人出现问题，没有来上班，主要简单的做做调整，这个餐馆是可以正常运行的。服务

 

员就相当于界面，把客户的需求传给厨师，把厨师的劳动成果返回给客户，厨师就相当于逻辑判断层，他只是负责做

 

菜，不管其他的，通过厨师依赖与采购员，根据采购员采购回来的材料来判断是否可以满足顾客的需求。采购员就相

 

当于数据访问层，采购员只负责按照厨师传过来的菜单去采购材料，需要其他的。

 

      从上面的例子来看，三层架构的稳定性相对于简单工厂来说是稳定一些的，不会因为数据库或者是用户界面

 

的更改就马上垮台，只要做一些简单的调整就可以了，这充分了体现面向对象的特点。

 

      其实三层架构我们并不陌生，它是来源于简单工厂，但是高于简单工厂，它把简单工厂的粒度更加细化了，

 

但是它们最终的目的是达到解耦。