开发模式和架构分析

开发模式

TDD

TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也就是说我们可以从测试的角度来检验整个项目。大概的流程是先针对每个功能点抽象出接口代码，然后编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。这一点和敏捷开发有类似之处。

TDD的好处,它能让你减少程序逻辑方面的错误，尽可能的减少项目中的bug，开始接触编程的时候我们大都有过这样的体验，可能你觉得完成得很完美，自我感觉良好，但是实际测试或者应用的时候才发现里面可能存在一堆bug，或者存在设计问题，或者更严重的逻辑问题，而TDD正好可以帮助我们尽量减少类似事件的发生。而且现在大行其道的一些模式对TDD的支持都非常不错，比如MVC和MVP等。

采用TDD这种模式的，必须具备以下几个条件，项目的需求必须足够清晰，而且程序员对整个需求有足够的了解，如果这个条件不满足，那么执行的过程中难免失控。取决于项目的复杂度和依赖性，对于一个业务模型及其复杂、内部模块之间的相互依赖性非常强的项目，采用TDD反而会得不尝失，这会导致程序员在拆分接口和写测试代码的时候工作量非常大。另外，由于模块之间的依赖性太强，我们在写测试代码的时候可能不采取一些桥接模式来实现，这样势必加大了程序员的工作量。

BDD

BDD指的是Behavior Drive Development，也就是行为驱动开发。这里的B并非指的是Business，实际上BDD可以看作是对TDD的一种补充，当然你也可以把它看作TDD的一个分支。

因为在TDD中，我们并不能完全保证根据设计所编写的测试就是用户所期望的功能.BDD将这一部分简单和自然化，用自然语言来描述，让开发、测试、BA以及客户都能在这个基础上达成一致。因为测试优先的概念并不是每个人都能接受的，可能有人觉得系统太复杂而难以测试，有人认为不存在的东西无法测试。所以，我们在这里试图转换一种观念，那便是考虑它的行为，也就是说它应该如何运行，然后抽象出能达成共识的规范。

DDD

DDD指的是Domain Drive Design，也就是领域驱动开发.DDD实际上也是建立在这个基础之上，因为它关注的是Service层的设计，着重于业务的实现，因此不可避免的以贫血模式为基础而存在。但是它最大的特别是将分析和设计结合起来，不再使他们处于分裂的状态，这对于我们正确完整的实现客户的需求，以及建立一个具有业务伸缩性的模型，是有很大帮助的。

贫血模式
贫血模型：是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层。

优点是系统的层次结构清楚，各层之间单向依赖，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。当然Business Logic是依赖Domain Object的。似乎现在流行的架构就是这样，当然层次还可以细分。

该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，所以就说只有数据没有行为的对象不是真正的对象。在Business Logic里面处理所有的业务逻辑，在POEAA(企业应用架构模式)一书中被称为Transaction Script模式。

充血模式
充血模型：层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。

它的优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。

缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。 其次，因为Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。

如果技术能够支持充血模型，那当然是最完美的解决方案。不过现在的.NET框架并没有ORM工具（不算上开源的NHibernate，Castle之类），没有ORM就没有透明的持久化支持，在Domain Object层会对Data Access层构成依赖，如果脱离了Data Access层，Domain Object的业务逻辑就无法进行单元测试，这也是很致命的。如果有像Spring的动态注入和Hibernate的透明持久化支持，那么充血模型还是能够实现的。

选择了.NET平台开发，就是选择了开发高效、功能强大应用简单，最适合的模型就是贫血模型，或表数据入口，既有编译器和语言平台很好的支持，也符合微软提倡的开发模式。如果跟潮流在项目中使用充血模型，现有的ORM工具都很复杂难用，光是维护大量的映射文件都成问题。说贫血不够OO，它的Domain Object不够丰富，能把项目做好了，有一定的扩展能力和伸缩行就行了，也不一定要讲究优雅的面向对象。正如SOA，讲究松耦合、高内聚，服务端给客户端提供的服务，也就是一系列的方法调用加上DTO而已，不管服务的内部是不是面向对象的实现，至少它暴露出来的是过程式的服务。

开发架构

习架构的时候，首先会想到分层的概念，分层架构比较经典的是三层架构，那么，什么是三层架构呢？它包括表现层，业务层，数据访问层；而对于一个新手来说，从抽象意义上的三层架构，逻辑上就划分为三个层



表现层充当系统的界面呈现以及UI逻辑的角色，也就是说，UI（用户界面）属于表现层；

举一个对于asp.net WebForm来说，人们喜欢把对于UI的控制逻辑（服务器控件的读取、设置、事件等等）写在页面的后置隐藏代码中，并且依赖业务逻辑层。当然，服务器控件支持数据绑定的功能，可以通过数据源进行绑定控件。这样就可以节省在后置隐藏中的代码。

因此，我们就可以把表现层分为UI用户界面以及UI逻辑



其中UI用户界面的实现方式有很多，包括ASP.NET，WinForm，WPF，Silverlight，移动Web，智能设备等等



将表现层中UI页面和UI逻辑分离的策略中，当前使用最多的两种模式是MVC模式和MVP模式

MVC模式，即模型-视图-控制器模式，通过视图触发并执行某个操作，调用控制器，通过控制器去操作业务层，最终返回模型，在视图中进行展示。这里的模型可以是一个领域模型（DM），也可以是一个数据迁移对象（DTO）。

MVP模式，即模型-视图-展示器模式，和MVC模式有点像，不同的是MVP中视图和模型是被完全分离出来的，视图中定义一个接口，而展示器通过调用该接口的方法以控制视图。因此，视图和模型是松散的，展示器也充当了一个控制器的角色，同时它也不依赖于UI技术。

另外再介绍一种模式PM（Preentation Model），它可以说是MVP的变体，在PM中，视图不定义接口，这里的模型只是表示视图状态的类，视图中的元素被直接绑定到模型属性上。例如在WPF中，WPF就先天的具有数据双向绑定机制以及事件通知属性机制。



在开始业务层之前,不得不说一个前提,在一个小型项目中,直接让表现层调用业务层,足以解决所有问题。但是，当项目大到使用多种表现形式，如使用了各种UI技术，ASP.NET，WPF，移动设备等等，就要考虑在你的表现层和业务层之间增加一个层，以至于让表现层和业务层解耦，因为业务层作为一个业务中间件的平台，最好不要暴露于表现层中，这个层就是传说中的服务层。架构图又演化为：



服务层实际上并不执行任何具体的工作，其功能在于组织各个业务对象,服务层将业务层所有的细节对表现层都隐藏起来,服务器将组织业务逻辑层中的组件,并且通过数据迁移对象(DTO)与表现层交互,因此就产生一个DTO模型。服务层消除了两个表现层和业务层之间的耦合，服务层可以实现一个远程接口，达到多UI技术甚至多平台上的通信。

为了实现服务的可重用性，需要使用服务接口，表现层通过规定的接口访问功能。服务的实现继承服务接口，而服务的实现专注于业务层的调用



对于服务层，常用的方法包括Web服务、.NET Remoting、Rest以及WCF技术。当然增加服务层也有缺点，假如使用WCF服务，会增加系统的调用开销，进而影响性能。



业务层中包含系统所需要业务过程上的实现，并与下层的数据访问层交互。

我们通常也叫做业务层叫做业务逻辑层，但我认为业务逻辑层是属于业务层的一方面，业务逻辑更专注于业务上逻辑算法的实现。因为业务层还可以包括其他的方面。

业务层必须包括对业务实体尽心建模的对象模型，表达了客户的所有策略和需求的业务规则，因此就产生了领域模型。

领域模型包括对实体的属性定义，方法定义以及实体与实体之间的关系。从这个角度上看，UML建模至关重要，通过对UML动态图和静态图的描述，可以映射到领域模型中。

从服务层刚才讲到了DTO模型，这里需要一个机制将DTO转化为领域模型，所以产生了DTO映射层（DTOMapper）。

另外业务层还包括核心中间件技术，包括第三方组件，以及工作流引擎等等。



业务层需要考虑到一些与数据访问层交互的设计模式，模式中包括事物脚本模式、表模块模式、活动记录模式、领域模型模式。

事物脚本模式是通过方法来执行业务流程，它是一个过程式模型，事物脚本的每个方法都有一个特定的事物脚本，它侧重于业务上一系列流程上的顺序操作，它实现起来很简单，但是它有个致命的缺点就是它会造成很多重复的代码。

表模块模式比起事物脚本模式，具有一定的结构，它的思想也很简单，每个数据表都定义一个业务组件（实体类，实体操作类），在.NET中更多的使用DataSet作为表模型的数据交互。但是它也有一个缺点就是它是从数据库驱动它不适合于大量的数据表以及数据表之间的复杂关系

活动记录模式中的对象中，可以包含数据和方法。它接近于数据表的结构，它的对象中执行方法中可以包含CRUD操作，验证算法，以及其他的计算功能。一般来说，领域模型不是太复杂，活动记录模式是个好选择。当然他也存在问题，同样地，它对于复杂的业务上，维护的成本也很高，并且如果需求变更导致数据库修改，就需要调整记录对象模型中的相关代码。

领域模型模式是从领域驱动设计中衍生来的，它是以业务为核心的设计模式。它对于复杂的业务逻辑，相当适用。前三种方式使用的是以数据驱动方式，数据驱动方式特点简单，但是当系统到了一定的规模后，就会到难以维护的程度。



数据访问层的目的很明确,主要作为提供数据持久化的功能，包括数据的读取和写入，另外还必须包括事务处理，并发控制等等。

操作数据库的方法可以有两种方式,ORM方式，ADO.NET方式。

ORM可以采用一些第三方的ORM框架来实现，ADO.NET采用ASP.NET自带的数据库操作来实现。

不同的数据库具有不同的持久化实现，因此这里添加一个存储仓库接口层，来适应不同的数据库实现，这里你可以使用IOC依赖注入方式进行数据库选型，可以利用Unity、Spring.NET、Castle的IOC容器等等。



最后各个层中都可以依赖于公共基础设施层。

公共基础设施层可以包括Common通用模块，Logging日志模块，Exception异常模块，Configuration配置模块，DI依赖注入模块，单元测试模块以及第三方组件（例如NHibernate、Sprint.NET、Castle、Quartz计划任务等等）



总结：项目类型、项目规模以及业务上的需求，都影响着系统架构的设计，系统架构并不是一层不变的，没有最好的架构，只有更好的架构，并且从项目中多思考系统的扩展性。文中对于架构的分析，只是从通常的角度上去考虑，在项目中，您还需要根据实际情况去做调整。