成也三层，败也三层

     这重构版的机房的计划早就开始，但开始的仅仅是计划，却迟迟没有行动的意思，于是频频地徘徊着，迷茫着。这都过去三个星期了，每次的停滞不前我都有自己的理由，但是我应该从心底里明白“成也三层，败也三层”。用三层对机房收费进行重构是一个坎儿，这就是一个对我们的的考验，挺过去的就是通往下一站的乘客，没过去应该就和编程无缘了吧。

     为什么？首先，机房重构是在第一遍机房的基础上用三层和设计模式的思维和理念来重新构建一个有你自己思想的机房收费。那到这里就明白了，门槛儿就是这个三层。从看完那段视频开始，我对三层的概念仅仅停留在这样的理解：

     首先，三层分为UI层、BLL层、DAL层。

     其次，UI层，说明白点就是我们平时程序中需要用到的界面，而也就是离用户最近的；BLL层就是俗称的逻辑层。提到逻辑，大家都懂，就是程序的思维过程，一步一步怎么往下走，怎么实现这样的思想过程。DAL，也就是数据访问层，顾名思义，就是帮助我们写一些语句来访问数据库。

     但也就是这对三层匮乏的理解，我的机房重构一直在原地踏步。昨天晚上，我们两个沟通了一下，究竟是什么导致我面对机房却全无兴趣。最重要的是我没有真正的理解三层，那么我也就不会将三层用到我的机房中，自然而然就不会往下进行，但眼看着别人都一步一步往前走，我的心里也不是滋味。另一方面，我现在还是有一种毛病，总为自己的一些时间拖延找一些很牵强的借口，我的番茄中机房重构的任务连续好几天一直是6/0，但更大的毛病是我会心里一直不舒服。。。。。

      最后，它们之间的引用关系：UI引用BLL，BLL引用DAL，而它们三个又都必须引用同一个叫做Model的实体类。

      通过昨天的分析，我对三层算是有了多一点的理解。

      首先，三层是为了解耦，切实履行”高内聚，低耦合“的思想，此话怎讲？三层中每一层与《大话设计模式》中讲到的“单一职责原则”，各司其职：UI负责界面，BLL负责逻辑，DAL负责一些对数据库的增删改查的语句，Model呢，就是将某一个界面对应的数据表中的数据取出，去和界面中输入的那些信息进行对比。而Model的数量大于等于数据表的数量，Model中的方法等于需要用到的数据表的字段名。如下图，登录窗体的Model中有UserName和PassWord两个方法。

      

      这样，一改之前逻辑、数据库语句和界面“大杂烩”的局面，将所有的工作进行分类整合，断开界面和数据库访问之间的直接联系，取而代之的是BLL层使用自己的逻辑调用ＤＡＬ中的一些方法和定义，然后结合Model中的方法实现界面所要求的操作。

　　  其次，引用的顺序：只有单向的引用。举个例子，假如我们让BLL层添加对ＵＩ的引用（正确的是ＵＩ引用ＢＬＬ层），那么我们就会收到这样的提示：

　　　　　

　　 而这里的引用是干嘛的，为什么要让三个层之间实现引用呢？

　   我是这样理解的：因为程序的代码已经被分为三部分，任意一个部分都不能直接构成整个程序，所以，引用呢就是使两个层之间产生联系，当ＵＩ需要使用ＢＬＬ中的一些方法和变量名称的时候确保可以顺利使用，而不是被限制或者自己重新命名，不引用自己重新命名不就产生冗余了，也不符合三层的”旨意“啊。所以说呢，引用就像是一种血缘关系，告诉它们三个它们是亲兄弟，只有三个人一起才能完成整个程序运行的使命，所以必须在彼此需要的时候出现并且伸出援手。从而一起完成它们的妈妈“三层”交给它们的任务！

　　　　这样一来，当我们需要对原来的程序进行修改，我们只需要轻松的对界面、逻辑和数据语言进行小改动，不至于惊动其他功能。因此在实现了解耦这一目标的同时，也达到了程序的可维护性和可扩展性的长远目标。

　　　　那么，这些理论的东西放到机房收费中应该怎么弄呢？？看我下一篇的博客《走在机房重构的路上》。