机房收费系统总结之图情结

         接着上次的总结，这次说下我的图情结。

         在这次机房收费系统画图中，对于实体层、数据访问层、表现层的划分，并没有太多的纠结，比较纠结的是业务逻辑层。

         这次重构，我采用了经典三层架构，还加了外观模式和抽象工厂加反射，在一次次的纠结中，罪魁祸首就是外观。

         首先说一下我的第一版，第一次画图没有用外观，业务逻辑层是基于表现层画的，所以有多少个窗体，在业务逻辑层就差不多有多少个类与之对应。例如登陆这条线：U层有一个frmLogIn的类，在B层有一个LogInManage的类，这个类里面有一个
LogIn（userInfo：UserInfo）：UserInfo的方法，这个方法调用需要用到的D层类的方法。

         后来让我的师父——松姐看了之后，跟我说了下他的看法：例如检查卡号是否存在，需要在很多类中要应用，那么就可以把它抽象出来。听了这个后，感觉挺对，然后就开始做了，不过现在看来当初自己做的有点过了——我将B层的粒度划分的太小了，几乎数据访问层的一个方法是一个类，这样在业务逻辑层几乎没有什么逻辑判断，这些逻辑判断全都堆砌到了外观层。

         这样一来，感觉业务逻辑层的任务没有做完，而是交给了外观层来帮它完成任务。如果说外观层也算作是业务逻辑层的话倒没有什么可说的，但是在图结构上B层也外观层是划分开的，我感觉这两个是不能混为一谈的。

         个人观点如下，欢迎各位拍砖：

         引用一下勇哥的一句话：三层其实就是一个外观模式！

         业务逻辑层需要处理完各种业务，而不是把自己的工作推给外观或者表现层。刚刚又看了一下书，感觉外观应用最多的应该是在维护的时候用。

         当一个界面用例比较多时，那么这一个界面需要实例化N个业务逻辑层，才能将这些功能一一实现，那么不如创建一个外观，将业务逻辑层的类进行整合，那么表现层在实例化时，只需要实例一个外观类，那么这个界面的内容就能全部实现。

         而并不是将业务逻辑层简单的执行以下return，然后在外观层进行判断。外观层就是外观层，它并不是业务逻辑层，所以对于判断的代码，在外观也是不应该出现的。

         总的来说，我感觉业务逻辑层应该这样：

         业务逻辑层应该面向用例，对于需要重复使用的代码进行抽象，那么主类和抽象出来的类应该是关联关系（个人观点）。

         如果一个窗体只有一两个功能，那么外观模式可有可无。如果一个窗体有好多个功能，那么就为这个窗体加一个外观，将所有的功能进行集成。在窗体实例化的时候实例该类，以达到表现层与业务逻辑层解耦的目的。