谈谈对于企业级系统架构的理解(转)

原文地址：http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html

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

这个是最基本的三层架构模式。

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

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

 

所以，咱们就能够把表现层分为UI用户界面以及UI逻辑：

UI用户界面的职责只是做为数据输入和输出后的展现工做。

UI逻辑的职责是负责业务逻辑层以及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就先天的具备数据双向绑定机制以及事件通知属性机制。

因此它特别适用于WPF，Sliverlight等等。

 

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

服务层实际上并不执行任何具体的工做，其功能在于组织各个业务对象,服务层将业务层全部的细节对表现层都隐藏起来,服务器将组织业务逻辑层中的组件,而且经过数据迁移对象(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容器等等。

 

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

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

最终图：

 

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

谢谢你们阅读！