最近接到一个临时任务：帮外国某知名公司分析一个项目架构。这个项目是两年前开发的，并且经过了几次升级。主要功能是管理客户、合作伙伴资料，提供在线业务等等，具体细节不用多说。

据客户说，他们在使用本系统的过程中发现了很多的问题，觉得已经不再满足他们的需求，希望我们能帮助他们评估一下当前的系统有哪些架构上的问题，并帮助他们发现未来可能发生的问题，从而决定是否需要开发新的系统

客户提供了很详细的文档，包括业务说明，系统架构，技术要点，部署方案等等。看完文档，对系统和客户期望有了一定的了解之后，开始干活儿！

系统是采用.Net技术构建的,基于.Net Framework 2.0,使用了ASP.NET, WinForm, WebService等技术,并使用了Enterprise Library中的Data Access， Cache，Log等功能。

我本人负责的是架构的分析。结合文档和源代码，没用1个小时，系统架构就很清晰了。其中发现了一些很普遍的问题，在这里跟大家分享一下：

1. 分层架构

分层架构是绝大部分企业软件都普遍采用的方案，但由于架构师水平的参差不齐，导致很简单的一个分层，出现了很大的差异。

大家都知道“3层架构”或者“多层架构”。有点理论里分3层，有点理论里分5层，还有分7层的。其实，在我看来分几层不重要，重要的是分层的目的。分层是为了什么的？简单的说就一句话：为了便于维护。

大家都知道，软件开发中“变化”才是永恒的。开发周期是死的（尽管可以一拖再拖，但总有一个发布的截至日期吧！），但后期的维护却是很不变得。不管是发布补丁也好，更新版本也好，其实都是为了能适应软件发布之后面临的各种各样的“变化”。

好，我们回到分层上来。分层，就是为了使系统结构更清晰，系统耦合性变小，使修改一处代码时，对其它的部分影响最小，这样就能以最小的代价应对变化带来的麻烦！所以，分层的第一要素，就是各层之间屏蔽细节，降低依赖，使各层具体实现变得透明（这也是SOA的其中一个重要思想）。我们可以通过各种办法来达到这个目的，面向接口编程，设计模式，架构模式等等，都可以帮助我们。

而我在此项目中看到的第一个重要的问题就是，系统分层不清楚。下面是分层的简图：

由上图可见，系统共分了 三层。但有一个问题，业务对象竟然贯穿了三层，这严重违反了分层的初衷。由于业务对象对数据存取层和展现层都可见，导致如果我们的业务对象发生了变化，就 要修改从数据存取、业务逻辑到展现层，这三个层次的所有相关代码。而且这个方案违反了分层的两个设计原则：

a. 下层对上层隐藏细节，只暴露接口。再此，本应属于业务逻辑层的业务对象被暴露到了展现层。

b. 上层对下层不可见。即下层不知道上层的存在，只提供接口。这里业务逻辑层的业务对象被数据存取层操作，会导致两个层之间纠缠不清，以至于会出现改动业务逻辑会影响数据存取方式的荒谬现象。

另外，强类型DataSet也有同样的问题（本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层）

软件设计中有一个很重要的原则就是：依赖倒置原则（DIP）

依赖倒置的意思是：调用者依赖被调用者的接口，而不是实现。

具体到此处就是：业务逻辑层应该依赖数据存取层的接口，而不是具体实现（强类型DataSet）。由于被调用者编程了抽象，而调用者变成了“实现”，所以与普通的面向对象的观念来说，依赖关系被倒置了，因此被称作依赖倒置原则。

依赖倒置在分层结构中是很重要的原则。希望每一个设计者都时刻把它记在心间吧，呵呵。

2. 面向接口编程

其实这跟上一个问题有密切联系。面向接口编程，是“依赖于抽象，而不是实现”的具体手段。不管是模块内部，还是个层次之间，面向接口是消除依赖的基础。

举一个简单的例子：本系统中业务逻辑层会调用数据存取层的方法，得到一些数据。比如调用一个PartnerAccess类的GetPartner的方法。PartnerAccess是数据存取层的一个具体类，负责Patrner表的所有增删改查操作。而业务逻辑层到处充斥着这样的语法：PartnerAccess partnerac = new PartnerAccess（）；partnerac.getPartner（）；

这就是一个典型的依赖于具体实现的方案。这样的后果是，业务逻辑层知道每一个数据表的数据结构，甚至是无需知道的细节，并且对数据层的每一个方法都了如指掌，到处都在使用。当我们开始修改PartnerAccess的其中一个方法的时候（比如增加一个参数）都要修改业务逻辑层的相关代码，但谁知道那些代码都在哪呢？只好重新编译吧，让编译器告诉我们。

而面向接口编程可以使我们避免这种问题。我们不再依赖于千千万万个PartnerAccess或者什么别的Access类，而是依赖一个IDataAccess的接口。这样，所有的数据存取都被标准化，我们的调用代码便的更简单，不会依赖任何数据库的结构，甚至不需要知道表的名字，有多少个字段等等。当我们增加一个OrderAccess类时，只需在数据存取层增加一个文件，一个类就好了，而不需要更改业务逻辑层的任何代码。

记住这个原则吧，它也可以说是面向对象的核心思想。会让你受益匪浅的！

3. 领域模型不清晰

从上面的图中可以看出来，本系统同时使用了两种领域模型，一种是业务对象（Business Object），一种是强类型DataSet（Strong Type DataSet），并且在每个层次中都使用了。

举个简单的例子：强类型DataSet被应用到ASP.NET的控件绑定上，用来显示数据。而业务对象被WebService暴露给客户端。

如果有人看过马丁·福勒的那本《企业架构模式》的话，应该会记得对领域模型的选择上有几种方案。其中业务对象和强类型DataSet都被提到了，并且说明了什么时候适用哪个模型。这里我不多说，感兴趣的朋友可以去看看那本书。

我想说的是，这里使用了两个模型并存的方案。这样就使得系统的领域模型不清晰，而且存在很多的冗余，例如出现了Partner业务对象和PartnerDS强类型DataSet并存的现象，尽管他们各有各的优缺点，但这样势必会造成领域模型的难于维护和代码可读性差的问题。

其实，特殊情况下，也可以两个同时使用，但要注意，由于业务对象是属于业务逻辑层的，而强类型DataSet是数据存取层的，所以他们都要在自己的范围内活动，不能被其它的层次存取。

到这里，有人可能会发现一个矛盾就是：使用单一业务对象的话，则会对数据存取层带来额外的开销，因为数据存取层不能知道业务对象的存在，就需要使用抽象，会带来一些代价。但如果使用单一的强类型DataSet的话，就会对业务逻辑层和展现层保留很多的内部数据细节，也会对系统架构造成一些影响，而且也不利于WebService的传输。

其实，一个合格的设计师，需要对这两种方案做各自的调整，都为自己所用，但只取他们的优势，而避免他们的劣势多带来的麻烦。

软件设计，何尝又不是一种取舍的艺术呢！

4. 强类型DataSet

上面讲到了业务对象和强类型DataSet两种领域模型的使用问题。其实强类型DataSet是.NET中很好的一种方案，它集成了数据库和面向对象两种优点，如果使用的好的话，会事半功倍，但使用不好的话，麻烦也很大。

在本系统中，强类型DataSet被赋予很多使命：从数据库中获取信息（数据存取层）、业务处理（业务逻辑层）和数据展现（展现层），贯穿了整个系统。这样就使得整个系统对强类型DataSet的数据结构非常依赖，一旦数据库发生变化，所有的代码（从数据存取到展现层）都要修改代码来。并且最要命的是强类型DataSet可以自动感知数据库的变化，自动更新同步。试想，如果你是这个系统的编码人员，会不会时时都提心吊胆呢？

很显然，这是一种糟糕的设计。在分层结构中，任何数据结构都不能贯穿始终，特别是与数据库结构。这回带来难以置信的麻烦。分层，其实就是要隔离这种变化给系统带来的连锁反应。使底层的修改不影响到顶层，反之亦然。

当然这是不是意味着强类型DataSet就不能使用了呢？当然不是的。强类型DataSet是非常好的连接数据存取层和业务逻辑层的纽带，因为它既有数据库结构又有对象特性。所以，只要我们能在两个层次中各自屏蔽细节，依赖于抽象而不是实现，强类型DataSet就可以在系统中发挥重要的作用。

5. 展现层太臃肿

本系统的很大一部分UI都是B/S的，采用ASP.NET构建。但我发现很多的WebPage中包含有大量的界面逻辑和业务逻辑，基本每个WebPage的代码都在几百行，有点甚至上千行。试想，这样的UI维护起来…

对于每一个开发者来说，大概都经历过这种痛苦，为了数据库的一个字段的修改，要从底层到顶层，全部修改一便，而且UI的修改是最麻烦的，往往是越改越烦！

其实对于UI的设计模式已经很成熟了，大家都知道MVC模式吧。就是一个很成熟，很实用的UI设计模式。另外还有MVP模式，这个是MVC的基础之上提出来的，跟MVC思想相同，但细节上有所不同而已。MVC模式网上有很多的资料，也有很多有名的应用案例。MVP则被广泛应用在微软P&P团队的很多项目中，诸如：Software Factory系列中都有应用。

下面是MVC模式和MVP模式的对比：

另外，关于两种模式的详细对比，可以参考另一位MVP:TreeLee的文章：ASP.NET MVC Framework与WCSF中MVP模式之小小比较。

6. 自定义事务

.Net framework 2.0中内置了对事务的支持，不但可以管理进程内的事务（包括SQLServer事务），还可以自动提升至MSDTC来管理分布式事务（包括WCF事务）。所以我们无需再编写任何事物的管理代码。

本系统中使用了Enterprise Library中的Data Access Application Block作为数据存取方案。但却没有很好地利用.Net framework 2.0的事务功能，而是自己写了很多管理事务的代码。例如使用一个TransactionContext类管理事务的执行，在很多数据存取的方法上支持传入TransactionContext类型的参数，用来管理事务边界。

这样不仅需要花费精力维护TransactionContext类，管理事务的执行，也使数据存取接口变的很复杂，臃肿。

其实我们完全可以利用TransactionScope这一.Net framework2.0中的事务处理类还管理事务。最简单的方式是：

Using(TransactionScope cpe = new TranscationScope())

{

数据操作方法1（）；

数据操作方法2（）；

…

数据操作方法N（）；

}

这样就可以自动提交和回滚事务了，而且可以根据实际情况，如果其中某个方法调用了分布式事务的话，可以自动升级为MSDTC事务。

关于如何使用.Net framework2.0中的事务功能，可以参考：Introducing System.Transactions in the .NET Framework 2.0。

7. 其它问题

还有一些其它的小问题，虽然不涉及到系统架构，但也会带来一些负面的影响，包括：

A．代码重复

a) 很多数据查询方法功能相同，只是返回的数据“格式” 不同（有的返回DataSet，有的返回DataRow，有的返回实体对象），为了调用方便，做了很多重载的方法，但没有考虑代码重复利用，造成大量的代码冗余。

B．公共模块

a) 设计者把系统中使用到的公共代码和枚举等等组织在一起，放在一个文件中，为各个项目所使用。其实这本来很好，但是我却发现，公共模块同时被三个层次引用，这样也是很不好的。这样会使得系统的分层结构遭到破坏，公共模块难于理解和使用。应该把属于各层专属使用的功能集成到各自的层中，每个层中设一个公共模块，这样既保障了分层的清晰，同时又很好地规划了公共模块。