浅谈“三层架构”

           今天我们来谈谈三层和传说中的“七层”。

           三层：（先看图）

           

           首先，我认为学习三层并不太难，体如今三方面：认识不难、理解不难、它所展现的内容不难。

           “认识三层”，网上随便一搜“软件的三层架构”云云，各种文章眼花缭乱。简单说三层就是指“表现层UI、业务逻辑层BLL和数据訪问层DAL”。表现层主要处理用户与界面的关系，业务逻辑层当然是主要处理业务逻辑，数据訪问层就是处理有关数据库的系列操作，比方增删改查等。

           其次，理解三层不难。我们先说说它是怎么来的，为什么要用三层。

           三层是从两层的基础上发展演变而来的，两层就是表现层和数据訪问层，也就是没有BLL层的架构。在一些小的系统中，有时候我们确实不须要分三层，直接从界面传入数据，再通过操作数据库处理些简单的逻辑，最后返回结果给用户就OK了。但一些大型企业级软件，若是缺少了分层架构，将是灾难性的。

           为什么这么说？我们能够非常明显看出来，添�了BLL层后，业务逻辑有了自己的容身之地，不再和界面、数据有过多的联系了，也就是“解耦”了。不管是开发人员还是维护者，最最不希望看到的就是系统里大把的耦合，耦合既不符合面向对象，也不符合软工的要求。就像是让你把十几种颜色不同的乱线头一一缕清，谁愿意干？

 

 

           “七层”：

           除了解耦，三层架构还方便了代码重用。在这里，我们浅浅地说一下关于“七层”的故事。以下是一张“七层”图。

          

           我在这里加了引號，是由于“七层”事实上并不一定是七层，你甚至能够分为五层、六层、八层都行！七层仅仅是一个象征性概念，就是三层加了一些设计模式的应用。上边这张图就是加了设计模式中的抽象工厂+反射、外观模式。

           详细解释下，外观模式继续为UI层和BLL层解耦，使得UI层仅仅须要调用Facade中的几个方法返回最后结果即可了，UI层终于与一切业务逻辑和数据处理无关；抽象工厂+反射+配置文件是用来方便数据库的，有了它，老板再也不操心你换数据库了！

           详细实现过程中，你还能够分出sqlHelper类来放一些经常使用数据库操作过程，主要是那些反复性的，以降低DAL层代码量；另外，DBHelper也是个不错的选择，里边存放的是SQL Server/Oracle/OLEDB/ODBC等各类型数据库连接方式，方便数据库切换。

           综上，我们说三层架构实现了代码重用。

 

 

           再回到三层：

           上面还说到三层展现的内容也不难。从上图我们能够看出，事实上三层就是调用与实现的过程。

           下层并不须要上层的存在，它仅仅须要完毕自己的功能就万事大吉了。

           比方UI层和BLL层，不论UI层长得什么样子，WinFrom也好、Web也罢，甚至不同的WinForm造型都无所谓，BLL层仅仅须要处理好业务逻辑即可了，从UI层接收用户信息，最后再给出一个返回信息给UI层。

           BLL层和DAL层也一样：DAL层从BLL层获得推断是否与UI层用户输入数据同样等指令（仅仅是一个样例）进行数据处理，最后给BLL层一个值（相应为布尔值），BLL层对该值进行逻辑加工，再返回给UI界面，这个过程就结束了。

          强调一下，三层之间并非无联系，而是联系非常弱。

          关于三层的难点，我觉得是三层在系统中的应用，如何在三层架构下实现一个良好的类图结构，是当下须要考虑的重难点，随着笔者机房收费系统重构的进行，我们再做分析吧。

          本文的不合理之处，还请各位读者提出宝贵意见。