再次谈起三层架构来，初识三层时的那种向往，那种青涩，已经不见了踪影，取而代之的是对分层的感慨。
分层，三层也好，七层也罢，都是将页面显示、业务逻辑控制、数据访问进行解耦。还有MVC和设计模式也是这样。只分UI,BLL,DAL这三层，只是实现了基本的解耦，但是耦合性还是很高的，尤其是对于中型及以上的系统来说，简单的三层并不能满足其需求。DAL提取出DBHelper，BLL中提取出Facade层，还有各层之间其实都应该加上接口。这样系统的灵活性才会大大提高。
对于B层的划分，有人说按数据表走，一个表一个类；有人说按窗体走，一个窗体一个类(PS:我这里是重构，有原系统做参考，如果是开发一个新系统，则没有这种说法)；有人说按用例走，一个用例一个类。合作开发完以后，我好好分析了一下这三者。第一种方法，B层的类会相对少一些，维护工作会比较轻松，不过假如增加一个功能，那么就得相应的修改B层的类，不满足开闭原则。第二种方法，局限性更大。只要修改窗体，就得修改类。这样给人的感觉，B层依赖于UI层。但是分层应该是上层依赖于下层。第三种方法，满足开闭原则，添加功能，直接添加一个类即可。但是不足的是B层中类太多了。分析之后。我觉得应该改善第三种方法，在B层包中，为每个表添加一个子包，然后对应B层的操作放到对应子包中。这样就不会太乱了。添加功能时，直接在对应的子包中添加类。一个用例一个类。满足了开闭原则和单一职责原则。
对于Facade层如何划分，暂时没有确定的想法。有2种观点：一是将有关系的类，相近的类放到一个外观类。另一种观点按UI层来划分。不过感觉第一种观点稍微科学一点。暂时没有更好的想法。
在个人版和合作版开发完后，感觉接口挺重要的，开发接口可以大大增加系统的灵活性。而且，每一层只要针对于接口进行编程即可。不用考虑下一层的具体实现。下一层如何更改都无关紧要，只要接口不变，那么系统运行无阻碍。在开发前期，先开发接口，这样上层接口在编程时，调用下层会很容易，且不易出错。调试的时候也很方便。
