三层架构之实体层以及外观

         昨天，七期师兄师姐们给我们讲解了一下三层和三范式。

         关于三层：

         对于三层的理解，一直在一步步的加深之中，不论理解的对与错，至少现在和别人说三层，能说出一点点的皮毛，但是再往深一点说，就不会了。

         听了昨天的讲解，发现最难理解的其实并不是B层，也不是D层，更不是U层，而是实体层。

         BLL层主管业务逻辑，也就是说和业务有关的放在B层。U层是表现层，主管和用户的互动，用户输入，以及向用户展示都是U层的事。D层为数据访问层，主管和数据库打交道。

         前些日子看了篇关于三层的文章，在他的文章里说验证是否为空等一系列放在B层。关于这个，仁者见仁，智者见智。有人认为只要涉及到判断，那么就应该放在B层，也有人认为，这个是与界面相关的，所以放在U层。

         放在B层的好处是什么呢？那就是U层的代码可以再少一点，在更换界面层的时候，新的U层只需要传值即可，这样的话B层就会变的特别臃肿。我感觉着也就是大家都说B层是最麻烦的原因了。

         我个人感觉最难理解的是实体层，这一层是“跳出三界外，不在五行中”。它不属于三层中的任何一层，但是三层每一层都与他关联。最初的理解是有多少个表，就最少有多少个实体类，每个实体类的属性为表的字段。

       慢慢的，觉得这样划分实体类是有问题的，因为涉及到多个表的时候，那么就返回不了实体类了，因而出现了基于视图创建实体类。宏哥的一句话更是点醒梦中人：其实你都可以将九个表的字段全部写到一个实体类里面。

       虽然大家都不会这样做，但是这个思想告诉我们，实体类并不是规定死的，他可以完全按照你的需要进行改造，怎么用更符合面向对象，就怎么用，没有那么多的条条框框。这也就是他“跳出三界外，不在五行中”的原因吧。

       而面对返回datatable，u或b层需要知道字段的问题，则是在实体层写一个参数为datatable类型的方法，那么了解字段的责任就交给了实体层，这样，就做到了u、b层与D层的解耦。

       我们画图的时候，有的人加了外观，昨天师姐问我们是否想过这些细粒度的包怎样对应粗粒度的包，这个其实并不太难，所以就不说了。下面附图再解释下个人对外观的理解吧（上篇中已经文字叙述了对外观的理解——机房收费系统总结之图情结）：

       这次的举例为上下机实例，首先我们看一下外观带逻辑的图：

在这个图里，B层是基于U层写的，但是在B层差不多之进行了return类似的语句，相应的判断几乎没有，这些工作都交给了外观层来解决。外观是用来解耦的，这样其实并没有达到解耦的目的，昨天开会的时候，勇哥说解耦最好的方法就是接口，而这里外观提供的并不是一个接口，而是类似于B层的一个类。用了外观，就好像把B层架空了一样，跟外观层直接调用数据访问层的感觉差不多。

下面在看下外观没有逻辑的图：

（上图中在B层省去了其他的关联关系）由于检测卡号是否存在以及检查是否正在上机要重复使用，那么在B层将其抽象出来以达到复用的目的。在这里，相应的逻辑都存在于B层之中，B层做了自己应该做的，并没有交给外观，所以个人感觉虽然说可以将细粒度的包和粗粒度的包对应，但是是有区别的。

下面再说下外观存在的意义，如果没有外观，那么将会是下面的图：

      

这样，U层需要知道B层的就太多了，耦合性太高。我们的系统简单，一个上机窗体里面就两个主要功能，但是一个窗体上面内容多的话，那U层和B层的对应关系不是很乱了么？这时外观就出动了。

在应用外观时，我们不能将B层应该做的放到外观做，就好比你D层的代码写到传参等一切都继续了，就差cmd的execute，然后你返回一个cmd，让他在B层execute吧（可能不恰当，但是道理是相同的）。

对于设计模式的理解，任重而道远，在自己的机房收费系统里面所用的设计模式，除了抽象工厂加反射利于更换数据库外，其他的功能感觉都有点牵强。

本来要写成两篇的文章，写到了一起，大家一定读累了，再次感谢您的拜读。

下回说一下机房收费系统所用的设计模式。