一、前言大家好，接近一年的时间没有怎么书写博客了，一方面是工作上比较忙，同时生活上也步入正轨，事情比较繁多，目前总算是趋于稳定，可以有时间来完善以前没有写完的系列，也算是对自己这段时间工作和生活上总结，同时也加深下自己对架构和设计方面的理解，由于本人的写作水平有限，所以在书写的深度和书写的格式上还有很多的缺点，还希望大家多多指出。

二、开篇本篇我们将针对系统架构中的分层进行讲述，分析不同分层模式的优缺点及使用的场景，当然我们会结合一些案例来介绍这些分层，通过案例来证明各种分层的好处和优缺点，本篇作为开篇主要是介绍这个分层系列中会讲述到的几种分层模式实践，由于很多分层模式也是自己在工作过程中总结和经验积累下来的，可能存在个人理解或用法上错误之处，还请大家指出，我予以及时更正。

三、内容提要1、前言2、开篇3、本文提纲4、分层模式4.1、分层架构介绍4.1、后端分层多层4.1.1、普通三层架构4.1.2、多层架构4.2、前端分层模式4.2.1、MVC模式4.2.2、MVP模式4.2.3、MVVM模式5、结束语6、系列进度7、下篇预告四、分层模式4.1、分层架构介绍架构首先是分为不同层次的和不同视图的，例如架构有五种视图：逻辑视图、物理视图、数据视图、运行视图、开发视图。

我们今天不讲解这几个不同的视图，而是讲解分层对于软件设计的意义及关注点，之前我也发过一片单机软件架构的文章，文章中提到了一个软件从简单到复杂的全过程，而软件架构也是一个迭代的过程，是一个循序渐进，不断完善的过程。

我们今天交流的主要是逻辑纬度的分层，关于物理视图的分层，本篇先不讲解，因为那块更复杂，同时也更重要，对于大型的互联网软件或大型的互联网网站，更关注的是物理架构方面的设计。

下面我们就来针对当前的一些分层模式来进行讲解，并且进行简要的分析和使用场景介绍。

4.2、后端分层架构一、普通三层架构三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务使用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

区分层次的目的即为了“高内聚，低耦合”的思想。

三层架构图对于传统的三层架构图，可能因为大家在实际的场景中，因为大家对这些分层运用的不同，会出现适应的场景的不同，而且有很多的大型软件或项目，都是采用三层架构，我们可以通过引入一些开源的组件或自定义组件来构建非常灵活或扩展性很强的分层结构，虽然是3层架构，但是却可以满足大部分的场景。

A、场景：最原始的三层结构可能如下：ThreeArchitecture.Entities：实体定义层，该层主要是完成各分层间数据传递并且最终通过该实体实现DAL层和数据库交互的数据传输。

ThreeArchitecture.DAL：数据访问层，通过调用实体层，通过编程，实现数据持久化，例如可以支持多种数据库，sqlserver、oracle、mysql、sqlite.ThreeArchitecture.BLL：业务逻辑层，通过调用实体层、数据访问层，实现整个业务系统的核心功能，完成系统业务的处理。

ThreeArchitecture.UI：用户界面交互层，用户通过该用户界面和业务系统进行交互，完成业务逻辑操作和交互。

根据上面的解决方案的分层及组织，下面针对以下几个场景来分析，分析三层架构中遇到的问题，应该如何解决这些问题。

1）、如果需要实现多数据库支持。

我想业务系统能够从sqlserver向oracle数据迁移，或反之。

这样在现有的项目结构方式，就无法满足，但是我们可以增加新的接口层来实现这个要求。

例如可以通过如下项目方式来组织：修改原有的项目划分结构，加入DAL.Interface层次。

定义数据访问接口，通过不同的数据访问实现，然后通过数据访问层工厂，来构建不同的数据库访问实例。

这块具体的代码我就不贴出了，应该比较简单。

同时原来的ThreeArchitecture.BLL 调用的不是直接调用数据库访问层实现，而是调用数据访问层接口。

不依赖于具体的实现，而是依赖接口，这样可以实现解耦，提供了很强的扩展性。

2）、如果我要求业务逻辑层实现也不一定固定，例如在医疗行业的话，每个医院的业务系统或业务流程都不相同，那么假设我们希望沟通统一的UI界面，而不是随着业务逻辑的改变而修改UI，那么我们就需要进行如下的设计：项目的结构方式类似上面的DAL层的变化。

在原来的基础上改进：ThreeArchitecture.BLL.Interface：定义业务逻辑接口，主要目标是隔离UI和业务逻辑实现间的依赖关系，将实现代码调用修改为接口调用方式。

ThreeArchitecture.BLL.A：A场景下的实现，A的业务逻辑。

ThreeArchitecture.BLL.B：B场景下的实现，B的业务逻辑。

3）、纵向和横向扩展性需求场景，例如场景变化灵活性较高时，工厂模式无法很好应对，需要维护大量的工厂代码。

可以采用开源的相关组件，来实现解耦及隔离，例如数据访问层可以采用Nhibernate或Entityframework来实现，关于Nhibernate的文章，园子里面已经有很多的文章介绍了，我就不介绍了，引入Nhibernate以后，项目的结构，回到如下模式ThreeArchitecture.DAL.Nhibernate：NHibernate实现数据访问层接口，Nhibernate支持目录主流的大部分数据库，所以不需要按照1）中的方案去做，只需要实现一次即可。

ThreeArchitecture.DAL.EntityFramework：EntityFramework实现数据访问层接口，EntityFramework支持Oracle,SQLServer，其他的数据库支持的不太好。

在上面的场景中，例如在A场景下，我希望使用A业务层、B场景下使用B实现，而且，不希望系统中维护大量的工厂代码，那么我们就请出来当前架构或框架设计的核心组件IOCIOC：控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是当前主流框架的核心。

控制反转还有一个名字叫做依赖注入（Dependency Injection）。

简称DI。

采用了IOC以后，接口和实现就可以通过配置的方式来动态的设置，而且调用的方式也变得更简单，不需要其他复杂的代码设定，目前市面上的IOC 容器很多，我了解的主要是以下几种：Unity：微软的轻量级IOC容器。

提供了比较强的注册和动态查找机制，同时提供了强大的AOP，几乎无所不在。

Autofac：Autofac是一款IOC框架，比较于其他的IOC框架，如，Unity，Castle等等所包含的，它很轻量级性能上也是很高的：参考java的sprint 框架的.net平台下的实现，比较强大。

Castle：Castle是针对.NET平台下的一个非常优秀的开源项目，从数据访问框架ORM到依赖注入容器，再到WEB层的MVC框架、AOP，基本包括了整个开发过程中的所有东西，为我们快速的构建企业级的使用程序提供了很好的服务Ninject：是一个快如闪电、超轻量级的基于.Net平台的依赖注入框架。

它能够帮助你把使用程序分离成一个个松耦合、高内聚的模块，然后用一种灵活的方式组装起来。

通过使用Ninject配套你的软件架构，那么代码将会变得更加容易编写、重用性强、易于测试和修改。

关于上面介绍的部分IOC容器的用法整体上来说都差不多，具体的大家可以网上搜索下，案例和demo比较多。

二、多层架构上面介绍了普通的三层架构，多层架构顾名思义就是在三层架构之上，通过扩展及使用场景的挖掘，衍生出来的适应不同场景的架构模式，下面我主要是来介绍以下几种多层架构模式A、服务层模式在上面介绍的3层架构模式中，存在一个缺陷，如果我们构建的软件或系统支持分布式或者需要对外提供服务的时候，这个场景就无法满足了，所以这个时候服务层就出现了，就是在BLL层的基础上进行包装，包装成可以对外提供调用的分布式服务。

经过改造后的项目结构如下：在项目中加入了03.解决方案文件夹，同时添加项目ThreeArchitecture.Service项目。

ThreeArchitecture.Service:主要是提供几个作用：1、将业务逻辑层进行封装，对外提供业务服务调用。

2、通过外观模式，屏蔽业务逻辑内部方法。

3、降低业务逻辑层和UI层的依赖，业务逻辑接口或实现的变化不会影像UI层。

4、降低UI层调用的请求次数及数据往返。

在上面的结构中，我们说了Service层次的作用，目前还少加入了一层，DTO(数据传输对象层)，该层负责屏蔽后端的实体层，将UI层需要的数据进行重新的定义和封装，在实际的业务场景下，后端实现或存储的数据远比用户需要的数据要庞大和负责，所以前端需要的数据相对来说要么是组合的，要么是抽取的，不是完整的，因为我们在设计数据存储格式上都会有一些额外的设计和考虑。

加入了ThreeArchitecture.DTO层后，前端的UI层，只是知道DTO的存在，同时前端需要的数据都在一个Dto中，这样，每次调用服务层的时候，只需要调用一次就可以完成所有的业务逻辑操作，而不是原来的直接调用业务逻辑层那样的，需要调用多次，对于分布式场景下，减少服务调用的次数，尤其重要。

B、DDD架构模式：Presentation Layer: 负责和客户端进行交互Application Layer: 负责协调领域层之间的交互Domain Layer: 软件的核心，所有相关的Domain information都在这，可以看成是Business Logic Layer，但不完全是Infrastructure Layer: 負責各層之間的交互溝通、資料存取、安全性管理及通用Library更常见的是如下层次我们建议的方式如下：Repository层使用ORM映射或SQL命令等方式把持久化数据转化为领域对象，然后根据业务逻辑设计对应领域层服务Domain Service 。

接着使用层进行操作上的协调，利用Repository、领域模型、领域层服务Domain Service 完成业务需要，再通过数据转换器把领域对象Domain Object转化为数据传输对象DTO。

最后，利用远程通讯技术把使用层的服务（Application Service）对外开放。

注意留意的是SOA系统中，UI表现层和Application Service使用层服务是实现分离的，表现层可以同时调用多方的远程服务来完成工作。

在上面的架构中还可以加入领域事件、查询接口、分布式服务层，来灵活运用和组合，来解决项目中适应场景的不同。