【机房收费系统】——从三层到七层

       开始机房也已经一段时间了，但是一直没有写东西，今天就来谈谈三层结构是如何到七层的吧！在谈论七层之前首先来回忆一下三层，三层架构是为了解决原来用户直接依赖数据库的问题，增加了业务逻辑层，降低层与层之间的依赖，从而来进行解耦的。这样做的优点就在于：使程序的结构更加明确，开发人员可以只关注整个结构的一层，可以很容易的用新的实现替换原有层次的实现。那么所谓的“七层”，则是加上外观和抽象工厂两种设计模式来进行的进一步解耦，这样更加符合设计的原则，使层与层依赖性更低。

       三层和七层的比较

       三层架构：

       

       七层架构：

        

       通过三层架构和七层架构的对比，可以很容易的看出，七层加入了Facade（外观类），Factory（工厂类）以及IDAL接口。接下来就简单说一下这样做的好处吧！

       添加外观类Facade

       之所以要这样做，是为了将业务逻辑层和表示层分开，降低他们之间的依赖。学过设计模式的朋友一定知道外观模式，它的定义是：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

       看完定义，估计大家也不会明白吧，举个简单的例子：假如U层需要调用B层中的很多的类，那它需要一个一个的去实例化，然后再调用他们的方法。可是在U层和B层之间添加了外观模式，就可以将这个工作放到Facade中去实现，然后U层调用Facade，这样就可以直接去调用B层中类的方法，并且由于外观的加入，U层根本不需要知道B层中有哪些类。从而减少了B层和U层之间的依赖。

       使用外观的前后对比图：

       

       抽象工厂（Factory）+接口（IDAL）

       抽象工厂可以说是设计模式中的核心，这里可以简单回顾一下抽象工厂的定义：提供一个创建一系列相关或互相依赖对象的接口，而无需制定它们具体的类。说的简单一点就是：工厂就是用来创建对象的，它将B层中对象的创建放到工厂中来实现。这样就可以让具体的创建实例过程与客户端分离，D层中具体的类名也被具体工厂的实现分离，不会出现到客户端代码中。

       除此之外，利用工厂中的反射机制很好的改进了对于类的实例化过程，并且通过接口实现了B层和U层的进一步解耦。

       总结：

       通过三层到七层的转变，将设计模式应用到实践，可以很好的帮我们完善程序的结构体系，使得我们的程序层次分明，编写代码瞬间变得简单起来，只要明白了这里面的层次结构，在层与层之间调用的时候就会清楚很多。在这段学习时间，也了解到了很多东西：DataTable的使用、泛型、SqlHelper等等。随着实践的增加，我的收获越来越多的。