当三层遇上设计模式
很多人，尤其是初学者感觉能敲出代码来就是强人，但是，当真正去学习软件工程，学习UML画图，学习设计模式，三层架构之后，发现，敲代码的都是打工的，而真正的技术牛人，是设计的。
最近忙着重构机房收费系统代码，写文档的时候就已经纠结和很久，这次画rose图，丝毫没有放过我的意思。
虽然这次是重构，但是，似乎之前的那次写的机房收费系统，也就起到了个了解业务的作用。
其实写机房收费需求的时候都纠结的要死，但是，这次的rose图可以说，因为是第一次用三册呢过画图，其实这也是我第二次画rose图，所以，直接让我纠结死了。
画有三层的机房收费系统rose图。
我最初的想法：三层分为UI层，BLL层，DAL层，UI层负责与界面的交互，DAL层负责与数据库的交互，BLL层负责UI层与DAL层的交互，逻辑很简单，于是按照界面，我画出了UI层，按照数据库我画出了DAL层，按照UI层与DAL层的联系，我画出了BLL层，因为但是没有记录，所有不能把原版展示给大家，这是我为了写这篇博客单独画的简略图：
但是感觉这样太简单了，你老是说三层是个坎儿，那么，它不能这么简单，可是我自作多情的在UI前面，加了一个windows form包，意思就是UI层是依赖于它画的，DAL层后面加了一个DATABASE包，和DAL层连接，现在想想当时是多么幼稚啊！其实虽然不知道应该画成什么样，但是我知道肯定不是我这个样子的，但是至于该怎么画，真的是一点头绪都没有，于是只好硬着头皮去找双双姐。
经过双双姐的一番点播，我不能说大彻大悟，但是像是被点醒了
首先，用例图是没问题的。这在文档中也写得清清楚楚，而且毕竟写过一次机房收费系统的代码
从用例出发，每一个用例几乎都需要调用数据库，大体都是对数据库的增删改查，但是，具体是如何操作的，增比较好多，基本上都是对整个数据库表字段的操作，大部分的修改和删除也好说，基本上都是以一个变量，然后进行修改和删除，关键是查，因为查可以分为很多种而且查出的数据库显示的字段一般也不一样，所以，要想画好DAL层，必须要对程序有一个比较好的理解。
所以，于是说下一步，不如说是正确画图的第一步，把所有的用例和数据库之间的调用，调用什么，调用结果画出一张图来，然后根据这张图写DAL层。这样，DAL层就很轻易的写好了。
但是，如果要写好一个程序，仅仅只有三层是远远不够的，就像，比如，我们现在用的是SQL server数据库，如果，突然用户要该需求，要用Access数据库，怎么办，考虑到程序的健壮性，所以，在BLL层与DAL层必须加以选择，因为从程序的设计角度来讲，灵活性，可扩展性，可维护性是最重要的，所以，就需要用到设计模式，我在这里选择的是抽象工厂模式。
具体参考见《大话设计模式》第十五章就不能换DB吗？——抽象工厂模式。
因为数据库调用比较多，中间用了一个单例模式，开控制客户的访问量。这样，即保证了程序的可灵活性可扩展性维护性，同时还对程序进行了很好的封装。
第二步，就是UI层了BLL层，UI层几乎就是有多少个窗体就有多少个UI类，从三层的解释中我们可以看到，BLL层是连接UI层与DAL层，它可以说是对DAL层的组装来满足UI层的调用，所有，BLL层可以说是一个组装层，比如说用户登录：用户登录时需要查询该用户是否存在，用户密码是否正确，如果正确，则还要给工作员工作记录表添加记录，所有他是有UserInquire和WorkLogAdd两项，这两项在UI层中是一个类，而在DAL层是两个，所有需要BLL层进行协调，但是，问题在于，若干个UI层的类与若干个DAL层的类之间相互访问，很混乱，如何避免这种混乱呢，这就需要用到外观模式，具体参见《大话设计模式》第十二长牛市股票还会亏钱？——外观模式。
外观模式很好的协调了UI层与DAL层之间的关系，使程序的可维护性变得更好。
我这个外观类有些大，为了展示全部，所有没有细分，但是最好是分一下类，比较容易维护，再出问题的情况下只需扩展，不用修改。
一下就是整个系统的包图：
第一次画图大概过程就是这样的，写的很轻松，但是真正画起来却真是百种滋味共上心头，万事开头难，想起来第一次写文档的纠结劲儿，不过，第二次写的时候就轻松很多，所以，此篇博客仅献给第一次画UML图的人，希望有用。