在我们刚开始学习架构的时候首先会想到分层的概念分层架构比较经典的是三层架构那么什么是三层架构呢它包括表现层业务层数据访问层而对于一个新手来说从抽象意义上的三层架构逻辑上就划分为三个层。这个是最基本的三层架构模式。表现层充当系统的界面呈现以及UI逻辑的角色也就是说UI用户界面属于表现层举一个对于asp.net WebForm来说人们喜欢把对于UI的控制逻辑服务器控件的读取、设置、事件等等写在页面的后置隐藏代码中并且依赖业务逻辑层。当然服务器控件支持数据绑定的功能可以通过数据源进行绑定控件。这样就可以节省在后置隐藏中的代码。因此我们就可以把表现层分为UI用户界面以及UI逻辑UI用户界面的职责只是作为数据输入和输出后的展示工作。UI逻辑的职责是负责业务逻辑层以及UI用户界面之间的数据交互并且尽可能地让UI逻辑不依赖于UI技术。其中UI用户界面的实现方式有很多包括ASP.NETWinFormWPFSilverlight移动Web智能设备等等。将表现层中UI页面和UI逻辑分离的策略中当前使用最多的两种模式是MVC模式和MVP模式。MVC模式即模型-视图-控制器模式通过视图触发并执行某个操作调用控制器通过控制器去操作业务层最终返回模型在视图中进行展示。这里的模型可以是一个领域模型DM也可以是一个数据迁移对象DTO。MVP模式即模型-视图-展示器模式和MVC模式有点像不同的是MVP中视图和模型是被完全分离出来的视图中定义一个接口而展示器通过调用该接口的方法以控制视图。因此视图和模型是松散的展示器也充当了一个控制器的角色同时它也不依赖于UI技术。另外再介绍一种模式PMPreentation Model它可以说是MVP的变体在PM中视图不定义接口这里的模型只是表示视图状态的类视图中的元素被直接绑定到模型属性上。例如在WPF中WPF就先天的具有数据双向绑定机制以及事件通知属性机制。所以它特别适用于WPFSliverlight等等。在开始业务层之前,不得不说一个前提,在一个小型项目中,直接让表现层调用业务层,足以解决所有问题。但是当项目大到使用多种表现形式如使用了各种UI技术ASP.NETWPF移动设备等等就要考虑在你的表现层和业务层之间增加一个层以至于让表现层和业务层解耦因为业务层作为一个业务中间件的平台最好不要暴露于表现层中这个层就是传说中的服务层。架构图又演化为服务层实际上并不执行任何具体的工作其功能在于组织各个业务对象,服务层将业务层所有的细节对表现层都隐藏起来,服务器将组织业务逻辑层中的组件,并且通过数据迁移对象(DTO)与表现层交互,因此就产生一个DTO模型。为了实现服务的可重用性需要使用服务接口表现层通过规定的接口访问功能。服务的实现继承服务接口而服务的实现专注于业务层的调用。对于服务层常用的方法包括Web服务、.NET Remoting、Rest以及WCF技术。本人比较建议使用WCF作为服务因为可以方便地通过配置达到远程调用服务的目的。服务层消除了两个表现层和业务层之间的耦合服务层可以实现一个远程接口达到多UI技术甚至多平台上的通信。当然增加服务层也有缺点假如使用WCF服务会增加系统的调用开销进而影响性能。业务层中包含系统所需要业务过程上的实现并与下层的数据访问层交互。我们通常也叫做业务层叫做业务逻辑层但我认为业务逻辑层是属于业务层的一方面业务逻辑更专注于业务上逻辑算法的实现。因为业务层还可以包括其他的方面。业务层必须包括对业务实体尽心建模的对象模型表达了客户的所有策略和需求的业务规则因此就产生了领域模型。PS如果这里你不使用领域模型那么需要采用业务规则层进行业务功能上的业务规则的验证和控制领域模型包括对实体的属性定义方法定义以及实体与实体之间的关系。从这个角度上看UML建模至关重要通过对UML动态图和静态图的描述可以映射到领域模型中。从服务层刚才讲到了DTO模型这里需要一个机制将DTO转化为领域模型所以产生了DTO映射层DTOMapper。另外业务层还包括核心中间件技术包括第三方组件以及工作流引擎等等。业务层需要考虑到一些与数据访问层交互的设计模式模式中包括事物脚本模式、表模块模式、活动记录模式、领域模型模式。事物脚本模式是通过方法来执行业务流程它是一个过程式模型事物脚本的每个方法都有一个特定的事物脚本它侧重于业务上一系列流程上的顺序操作它实现起来很简单但是它有个致命的缺点就是它会造成很多重复的代码。表模块模式比起事物脚本模式具有一定的结构它的思想也很简单每个数据表都定义一个业务组件实体类实体操作类在.NET中更多的使用DataSet作为表模型的数据交互。但是它也有一个缺点就是它是从数据库驱动它不适合于大量的数据表以及数据表之间的复杂关系。活动记录模式中的对象中可以包含数据和方法。它接近于数据表的结构它的对象中执行方法中可以包含CRUD操作验证算法以及其他的计算功能。一般来说领域模型不是太复杂活动记录模式是个好选择。当然他也存在问题同样地它对于复杂的业务上维护的成本也很高并且如果需求变更导致数据库修改就需要调整记录对象模型中的相关代码。经典应用LINQ-TO-SQL以及Castle ActiveRecord。领域模型模式是从领域驱动设计中衍生来的它是以业务为核心的设计模式。它对于复杂的业务逻辑相当适用。前三种方式使用的是以数据驱动方式数据驱动方式特点简单但是当系统到了一定的规模后就会到难以维护的程度。数据访问层的目的很明确,主要作为提供数据持久化的功能包括数据的读取和写入另外还必须包括事务处理并发控制等等。操作数据库的方法可以有两种方式,ORM方式ADO.NET方式。ORM可以采用一些第三方的ORM框架来实现ADO.NET采用ASP.NET自带的数据库操作来实现。不同的数据库具有不同的持久化实现因此这里添加一个存储仓库接口层来适应不同的数据库实现这里你可以使用IOC依赖注入方式进行数据库选型可以利用Unity、Spring.NET、Castle的IOC容器等等。