三层究竟如何?

近日看到了一篇关于反三层的文章,手也痒痒了,就牺牲些时间,拿出来把这个老得掉牙的话题拿出重谈。

1. 什么是三层

很多人爱把三层架构和MVC混为一谈,但是我们可以从最简单的角度去考虑他们的不同:

在设计模式中一般都会有这样一章,MVC设计模式,而从没见过哪本书中有写过三层架构设计模式。

回归三层,三层一般来讲分为两类:

A. 物理上的三层架构

B. 逻辑上的三层架构

现在就逐个谈起,来看下究竟三层是否要走开。

2. 逻辑三层架构

逻辑三层架构从概念上看很容易,用户界面层,业务逻辑层,数据访问层。每一层都有自己所专有的职责。

三层架构是一切企业级架构的核心,直至Petshop中的七层,或者是一般企业中的五层都是以三层做为一个中心,在这里,我们可以说N=3。

用户界面层专职显示工作,与用户直接打交道。

业务逻辑层用于做一些复杂的业务处理。

数据访问层用于与数据库做一个交互,做常规的增删改查的操作。

这些很简单,点到为止。

3. 物理三层架构

物理三层架构是以逻辑的三层架构为基础的。如果没有了逻辑的三层,就根本谈不上物理三层架构的部署。

什么是物理三层架构?

从简单了说就是每一层都分别做成一个组件,如业务逻辑组件,业务实体组件,数据访问组件等。

再到麻烦了一些就是构建分布式系统,例如将业务逻辑层与数据访问分别部署再不同的服务器上。

4. 再论存储过程

存储过程作为一个SQLAS,与每门语言一样,也有着自己的优点和缺点。

来与数据库打交道无非三个方法:

A. 在程序逻辑中书写SQL语句,其中包含SQL字符串拼接最为常见

B. 在数据访问层使用ORM框架,在.NET项目中以LINQ TO SQL和NHibernate为主。(其实两者在实际项目中都不常用)

C. 使用存储过程

我们来分析一下他们之间的优缺点:

在程序逻辑中写SQL语句是很难处理复杂业务逻辑的,困难的引号匹配,复杂的字符串拼接过程,以及字符串拼接过程中的效率损失是我们不得不考虑的。

ORM框架是一个好办法,这个我不报什么怀疑意见,但是LINQ TO SQL略显蹩脚的语法,让常规程序员在C#和LINQ之间来回转换不是件容易事。NHibernate就不说了,这个在中国大多数公司来说还算是个非主流框架,而且与VS的集成不是很令人满意。

于是,处理复杂逻辑,如复杂的事务处理时,存储过程几乎成了唯一的方法。

但是,存储过程一样有着他的致命缺点,就是他的移植性很差,

A. 当我们的项目更换数据库时,我们就要把存储过程完整地去拷贝到另外一个数据库,然后考虑他们的兼容问题。

B. 当我们修改数据层访问代码时,我们需要动的不再是应用程序服务器的代码,而是数据库端的代码,这是稍显痛苦的地方 。

5. 三层的优点

现在有人去质疑三层,让三层走开,问题不在于三层。而在于他错用了三层。好刀要用在刃上,否则,恐怕只会弄巧成拙。

那么下面就说三层的优点究竟在哪?

A. 正如上面而言,逻辑上的三层是物理上三层的前提条件。

B. 三层可以让团队开发中,每个成员有着自己的关注点,而且利于小组成员的分工。

C. 重用数据访问层和业务逻辑层

D. 多语言协作(如数据访问层用vb,业务逻辑层用C#,情况很少见)

E. 一定程序上的易维护,但我个人认为这点体现的不明显,就像那位兄弟讲的那样,如果修改一个字段,需要在三层都进行修改。

6. 三层不三层

究竟是三层还是不三层,这一直是困扰很多人的问题。

正如每一种设计模式一样,这些都是一把双刃剑,用得好了会让你很方便,但是用错了却是适得其反。

是否三层,要纵观整个项目,然后去提前挖掘他的潜在变化点,然后再去想,如果这个项目用了三层对你有什么好处。

如果你想不到,那么就不要去三层。

常用三层的情况如下:

A. 产品型公司需要向上屏蔽底层细节,因此需要封装好很多访问以及业务逻辑,这个时候必须三层。

B. 项目很大,需要多成员合作,让一个成员既关注顶层的业务逻辑,又要关注页面美观,还要去注意数据访问的效率,这是不现实的。

C. 项目巨大,需要应用程序逻辑分布式。

7. 三层之扩展

在我所有的文章中,都在强调思想的重要性,我不喜欢被前人去限制住自己的思路,不喜欢轻易相信书上的观点,除非被我证实过。本篇也是一样。

究竟是三层,我觉得三层本就是一个思想,没必要说这样就是三层,那样就不是三层,这就把知识学的太死了。

还记得国外哪位大师给AJAX下的定义:只要能够提高用户体验的技术,我们就将之统称为AJAX。

其实,我个人认为三层也是一样:能够让我们的项目适应变化,可重用,方便程序员的架构方法,我们就可以称之为三层。

8. 扩展三层分类

A. 简化版三层:

当业务逻辑简单时,就把业务逻辑层简化,于是就形成了这样的结构:

.aspx为用户界面层 .aspx.cs为业务逻辑层 .cs单独搭建数据访问层

B. 一些变化

通常的公司都会有自己数据访问类,就像Petshop中的SqlHelper。我们也可以把这单独叫成一层,不过这都是概念问题了。

C. 分出业务逻辑和业务实体

对于很多项目来说,业务逻辑处理都是相对复杂的,说个简单的,比如在登陆界面,当传出密码到存入数据库,就需要一个加密的过程,我们就可以把这个过程封装到业务逻辑层内。另外,比如一些复杂的流程处理,我们同样可以在业务逻辑层去。

业务实体就不说了,这个很常见。

D. 无业务实体

在很多办公OA的项目中,数据往往是无实体的,因为用户可以根据自己的选择去动态地构建数据库表字段,因此这个时候,业务实体就没有存在的必要了。

E.  极端简化

在很多小项目中,业务流程简单,数据处理容易,更没有一些复杂的操作,没有团队合作,那么我们就没有必要去分层。这个时候的分层只会让我们的编码量以及维护量更大。那么这种情况算什么?

我之前提过这个概念,只要能够让我们的项目适应变化,可重用,方便程序员的开发,我就把他叫做三层,那么这么来说,这种最简单的方式其实我们也能把他勉强叫成是“三层”吧。

9 . 总结

三层不三层,三层要怎么三层,这本来就是一个很难去抉择的问题。

所以,我还是那个观点,适应变化的架构方式就是最好的方式。

posted @ 2009-05-25 17:35  飞林沙  阅读(4341)  评论(36编辑  收藏  举报