今天我们来谈谈三层和传说中的“七层”。
三层:(先看图)
首先,我觉得学习三层并不太难,体现在三方面:认识不难、理解不难、它所展现的内容不难。
“认识三层”,网上随便一搜“软件的三层架构”云云,各种文章眼花缭乱。简单说三层就是指“表现层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界面,这个过程就结束了。
强调一下,三层之间并不是无联系,而是联系很弱。
关于三层的难点,我认为是三层在系统中的应用,怎样在三层架构下实现一个良好的类图结构,是当下需要考虑的重难点,随着笔者机房收费系统重构的进行,我们再做分析吧。
本文的不合理之处,还请各位读者提出宝贵意见。
浅谈“三层架构”