三层架构的是与非

我们的系列还在继续，因为我们的项目还没有完成。在上篇文章《目标模型和现实模型》中我们的小组解决的是需求问题，我们的系统要满足的是目标模型，对目标模型的描述就是我们的需求定义。接下来我们需要考虑的是系统的实现。在讨论之前，我们先回顾一下我们这个Team的几个角色：

项目经理：王涛

系统架构师：李帅

高级开发工程师：赵构

开发工程师：若干（我们在后面的章节中将逐步介绍）

 

系统设计或者架构是技术组来负责的，其组成如下：

组长：系统架构师 李帅

高级开发工程师 赵构

开发工程师，张昊。

李帅是一个资深的开发工程师，在很多项目中做过技术负责人。根据过往的经验，他提出系统应以三层架构为基础进行设计。那么三层架构又是什么呢？

三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。

 

       1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

 

　　2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

 

　　3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。

 

这套架构在过往的项目中采用很多，相对也比较成熟，但问题也很多。代码维护量很大，随着时间的推移，也越来越不经济。所以，李帅就此与王涛进行了深入讨论。

李帅认为采用三层结构有如下：

1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、扩展性强。不同层负责不同的层面，如PetShop可经过简单的配置实现Sqlserver和oracle之间的转换，当然写好了也可以实现B/S与C/S之间的转换
7、安全性高。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
8、项目结构更清楚，分工更明确，有利于后期的维护和升级

但王涛需要站在更高的层面来看待这个问题：

三层架构较之于不分层的架构明显是进步了很多，对编程进行了分工，使得程序更加明晰。但这种三层架构仍然是一种面向过程（或者功能）的思维方式（虽然采用了面向对象的编程语言），业务逻辑大多写在静态方法中，这些静态方法挂在一个个伪对象下，很多相同的功能在不同的对象下重复，程序员为了完成某个功能，又难得在各个业务类下找这些方法，就会大量的写一些他自己看得懂的业务方法。如此程序代码程几何级数增长，代码的可维护性变得越来越差。这是程序员常说的“直上直下”。其根本原因是其不是真正的面向对象的思维方式，而只是传统的面向过程方法在现代技术条件下的一个变胎。