浅谈“三层架构”

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

           三层：（先看图）

           

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

           “认识三层”，网上随便一搜“软件的三层架构”云云，各种文章眼花缭乱。简单说三层就是指“表现层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界面，这个过程就结束了。

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

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

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