先睹为快
来一张经典的七层机房收费系统包图，PS:本人将 SQLHelper类单单拿出来，可将SQLHelper类归到 D层中，不影响使用。对于不清楚SQLHelper类运用者，可参见【VB.NET 机房收费系统】___爱上视图（View）
三层版机房收费系统
我们直接 UI—>BLL—>DAL ,通过层与层之间传递实体，最后返回实体，达到我们要的目的。一旦系统的规模扩大，功能增加仅仅的三层不足以应付需求的增加。
层与层之间的耦合度高。
牵一发而动全身，万一用户要求增加功能，那又必须在UI层实例化BLL对象，调用BLL层的方法；在BLL层实例化DAL对象，定义UI层声明的方法；在DAL层定义BLL层声明的方法，连接数据库，对数据进行增删改操作。这系统一错，那就崩了，耦合度太高了
代码的复用性底。
这……很熟悉……很熟悉……有木有……有木有……
在充值、退卡、查询余额、查询充值记录、上机、下机等窗体都需要判断卡号是否存在，每每有一个窗体需要查询卡的信息时都来一次判断卡号是否存在，来一次调用数据库。大大增加了系统运行时间，同时大大的累积了代码量。
七层版机房收费系统
在UI层与BLL层中间夹了个外观，从这点看U层、B层之间的耦合度减低了吧（这不是重点，重点是那么多种设计模式，为嘛单单只让外观模式加在U、B层之间。PS：请期待小编的下一篇博客【外观模式——重构机房收费系统】）一个抽象工厂+反射解了BLL层与DAL层之间的耦合，同时提高了代码之间的复用性。
先不说七层版机房收费系统是如何如何的好，用实例来说话。
三层VS七层机房收费系统
每一新阶段的程序设计都一Hello World开始……那就从机房收费系统最原始的用户登录开始吧。
在次要强调的是，在DAL层中 大多数我们是以表来分类，有几张表就有几个DAL类，
对于 外观层，这里我想给大家提供几条线供大家思考：
1、外观用用户级别划分，几个功能就有几种外观类，每一种外观类分别定义几个相应function来调用B层的一个类（按照功能划分）。
2、外观用用户级别划分，几个功能就有几个function，B层用表来划分，跟IDAL层分类相同，外观中的Function调B层的时候，可能要看清楚了。
3、外观按照界面（用例）划分，一个外观几个function，B曾可以用表来分，也可以用功能划分。
本人是以 功能划分的，一般用户外观类，操作用户外观类，管理员用户外观类，用户登陆外观类，上下机外观类。
一千个读者，就有一千个哈姆雷特，希望大家多多交流。