我们的系列还在继续,因为我们的项目还没有完成。在上篇文章《目标模型和现实模型》中我们的小组解决的是需求问题,我们的系统要满足的是目标模型,对目标模型的描述就是我们的需求定义。接下来我们需要考虑的是系统的实现。在讨论之前,我们先回顾一下我们这个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、项目结构更清楚,分工更明确,有利于后期的维护和升级
但王涛需要站在更高的层面来看待这个问题:
三层架构较之于不分层的架构明显是进步了很多,对编程进行了分工,使得程序更加明晰。但这种三层架构仍然是一种面向过程(或者功能)的思维方式(虽然采用了面向对象的编程语言),业务逻辑大多写在静态方法中,这些静态方法挂在一个个伪对象下,很多相同的功能在不同的对象下重复,程序员为了完成某个功能,又难得在各个业务类下找这些方法,就会大量的写一些他自己看得懂的业务方法。如此程序代码程几何级数增长,代码的可维护性变得越来越差。这是程序员常说的“直上直下”。其根本原因是其不是真正的面向对象的思维方式,而只是传统的面向过程方法在现代技术条件下的一个变胎。