阅读文件夹：

• 1.背景介绍
• 2.简要回想下传统三层架构
• 3.企业级应用分层架构（现代分层架构的基本演变过程）
  • 3.1.服务层中应用契约式设计来解决动态条件不匹配错误（通过契约式设计模式来将问题在线下暴露出来）
  • 3.2.应用层中的应用控制器模式（通过控制器模式对象化应用层的职责）
  • 3.3.业务层中的命令模式（事务脚本模式的设计模式运用，非常好的隔离静态数据）
• 4.服务层作为SOA契约发布后DTO与业务层的DomainModel共用主要的原子类型
• 5.两种独立业务层职责设计方法（能够依据详细业务要求来搭配）
  • 5.1.在应用层中的应用控制器中协调数据层与业务层的互动（业务层将绝对的独立）
  • 5.2.将业务层直接依赖数据层的关系使用IOC思想改变数据层依赖业务层（业务层将绝对独立）（比較优雅）
• 6.总结

1.背景介绍

接触分层架构有段时间了，从刚開始的朦朦胧胧的理解到如今有一定深度的研究后。认为有必要将自己的研究成果分享出来给大家。互相学习，也是对自己的一个总结。

我们每天面对的项目结构能够说差点儿都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构。少不了业务层、数据层。这两个层是比較重要的设计点，看似这两个层是互相独立的，可是这两个层怎样设计真的还有非常多比較微妙的地方，本文将分享给大家我在工作中包含自己的研究中得出的比較可行的设计方法。

2.简要回想下传统三层架构

事实上这一节我本来不打算加的，关于传统三层架构我想大家都应该了解或者非常熟悉了，可是为了使得本文的完整性，我还是简单的过一下三层架构，由于我认为它能够使得我后面的介绍有连贯性。

传统三层架构指将一个系统依照不同的职责划分层三个主要的层来分离关注点，将一个复杂的问题分解成三个互相协作的单元来共同的完毕一个大任务。

1.显示层：用来显示数据或从UI上获取数据。该层主要是用来处理数据显示和特效用的，不包含不论什么业务逻辑。

2.业务层：业务层包括了系统中全部的核心业务逻辑，不包括不论什么跟数据显示、数据存取相关的代码逻辑。

3.数据层：用来提供对详细的数据源引擎的訪问。主要用来直接存取数据，不包含业务逻辑处理。

其有用文字描写叙述这三个层的基本职责还非常是比較easy的，可是不同的人怎样理解并设计这三个层就形态各异了，反正我是看过非常多各种各样的分层结构，各有各的特点，从某个角度讲都非常不错，可是都显得有点乱。由于没有一个统一的架构模式来支撑。代码中充满了对分层架构的理解错位的地方，比方：常常看见将“事物脚本”模式和“表模块”模式混搭使用的，导致我最后都不知道把代码写在哪里。提取出来的代码也不知道该放到哪个对象里。

层虽简单可是要想运用的好不easy，毕竟我们还是站在一个比較高的层面比較笼统的层面来谈论分层结构的。一旦落实到代码上就全然不一样了。用不用接口来隔离各层，接口放在哪个层里，这些都是非常微妙的。当然本文不是为了说明我所介绍的设计是多么的好。而是给大家一个能够參考的样例而已。

言归正传。三个层之间的调用要严格依照“上层仅仅能调用直接下层。不可以越权，而下层也不可以调用自己的上层”，这是主要的层结构的调用约束，仅仅有这样才干保证一个好的代码结构。显示层仅仅能调用业务层。业务层也仅仅能调用数据层，事实上就是这么简单，当然详细的代码设计也可以大概归纳为两种，第一种是实例类或静态类直接调用。另外一种是每一个层之间加上接口来隔离每一个层，使得測试、部署easy点。可是假设用的不好的话效果不大反而会添加复杂度，还不如直接使用静态类来的直接点，可是用静态类来设计业务类会使多线程操作非常难实施，略微不注意就会串值或报错。

3.企业级应用分层架构（现代分层架构的基本演变过程）

上节中我们基本了解了传统三层架构的类型和职责，本节我们来简介一下现代企业应用分层架构的类型和职责。

随着企业应用的复杂度添加，在原有三层架构上逐渐演化出如今的面向企业级的分层架构，这样的架构能非常好的支持新的技术和代码上的最佳实践。

在传统的三层结构中的业务层之上多了一个应用层也但是说是服务层。该层是为了直接隔离显示层来调用业务层。由于如今的企业应用基本上都在往互联网方向发展。对业务逻辑的訪问不会在是从进程内訪问了，而是须要跨越网络来进行。

有了这一层之后会让原本显示层调用业务层的过程变得灵活非常多，我们能够加入非常多灵活性在里面，更为重要的是显示层和业务层两个独立的层要想全然独立是必需要有一个层来辅助和协调他们之间的互动的。在最早的三层架构的书籍中事实上也提到了“服务层”来协调的作用，为什么我们非常多的项目都不曾出现过，当我自己看到书上有解说后才恍然大悟。（该部分能够參考：《企业应用架构模式》【马丁.福勒】。第二部分。第9章“服务层”）

图1：（逻辑分层）

应用层中包括了服务的设计部分。应用层的概念略微大一点，里面不仅不含了服务还包括了非常多跟服务不相关的应用逻辑。比方：记录LOG，协调基础设施的接入等等，就是将服务层放宽了理解。

图2：（项目结构分层）

在应用层中包括了我们上述所说的”服务“。将”服务层“放宽后形成了如今分层架构中至关重要的”应用层“。应用层将负责总体的协调”业务层“和”数据层“及“基础设施”，当然还会包括系统执行时环境相关的东西。

3.1.服务层中应用契约式设计来解决动态条件不匹配错误（通过契约式设计模式来将问题在线下暴露出来）

此设计方法主要是想将动态执行时条件不匹配错误在线下自己主动化回归測试时就暴露出来。由于服务层中的契约可能会面临着被改动的危急性，所以我们无法知道我们本次上线的契约中是否包括了不稳定的条件不匹配的危急。

利用契约式设计模式能够在调用时自己主动的运行契约公布方预先设定的契约检查器，契约检查器分为前置条件检查器和后置条件检查器。我们来看一个简单的样例。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks; 

namespace CompanySourceSearch.Service.Contract
{
    using CompanySourceSearch.ServiceDto.Request;
    using CompanySourceSearch.ServiceDto.Response; 

    public interface ISearchComputer
    {
        GetComputerByComputerIdResponse GetComputerByComputerId(GetComputerByComputerIdRequest request);
    }
} 

namespace CompanySourceSearch.ServiceDto
{
    public abstract class ContractCheckerBase
    {
        private Func<bool> checkSpecification;
        public Func<bool> CheckSpecification
        {
            get
            {
                return this.checkSpecification;
            }
            private set
            {
                this.checkSpecification = value;
            }
        } 

        public void SetCheckSpecfication(Func<bool> checker)
        {
            CheckSpecification = checker;
        } 

        public virtual bool RunCheck()
        {
            if (CheckSpecification != null)
                return CheckSpecification(); 

            return false;
        }
    }
} 

namespace CompanySourceSearch.ServiceDto.Request
{
    public class GetComputerByComputerIdRequest : ContractCheckerBase
    {
        public long ComputerId { get; set; } 

        public GetComputerByComputerIdRequest()
        {
            this.SetCheckSpecfication(() => ComputerId > 0/*ComputerId>0的检查规则*/);
        }
    }
}

namespace CompanySourceSearch.ServiceDto.Response
{
    using CompanySourceSearch.ServiceDto; 

    public class GetComputerByComputerIdResponse : ContractCheckerBase
    {
        public List<ComputerDto> ComputerList { get; set; } 

        public GetComputerByComputerIdResponse()
        {
            this.SetCheckSpecfication(() => ComputerList != null && ComputerList.Count > 0);
        }
    }
} 

相同Response类也在构造函数中初始化了条件检查器为：ComputerList不等于NULL而且Count要大于0。

还是那句话样例是简单了点。可是设计思想非常不错。

对前置条件检查器的运行能够放在client代理中运行，当然你也能够自行去运行。

后置条件检查器事实上在普通情况下是不须要的，假设你能保证你所測试的数据是正确的，那么作为自己主动化測试是应该须要的。当时维护一个自己主动化測试环境非常不easy，所以假设你用后置条件检查器来检查数据动态变化的环境时是不太合适的。

3.2.应用层中的应用控制器模式（通过控制器模式对象化应用层的职责）

应用层设计的时候大部分情况下我们都喜欢使用静态类来处理,静态类有着良好的代码简洁性,并且还能带来一定的性能提升。可是从长远来考虑静态类存在一些潜在的问题，数据不能非常好的隔离。反复代码不太好提取，单元測试不太好写。

为了可以在非常长的一段时间内似的项目维护性非常高的情况下还是建议将应用控制器使用实例类设计，这里我喜欢使用“应用控制器”来设计。它非常形象的表达了协调前端和后端的职责，可是详细不处理业务逻辑，与MVC中的控制器非常像。

namespace CompanySourceSearch.ApplicationController.Interface
{
    using CompanySourceSearch.Service.Contract;
    using CompanySourceSearch.ServiceDto.Response;
    using CompanySourceSearch.ServiceDto.Request; 

    public interface ISearchComputerApplicationController
    {
        GetComputerByComputerIdResponse GetComputerByComputerId(GetComputerByComputerIdRequest request);
    }
} 

namespace CompanySourceSearch.ApplicationController
{
    using CompanySourceSearch.ApplicationController.Interface;
    using CompanySourceSearch.ServiceDto.Request;
    using CompanySourceSearch.ServiceDto.Response; 

    public class SearchComputerApplicationController : ISearchComputerApplicationController
    {
        public GetComputerByComputerIdResponse GetComputerByComputerId(GetComputerByComputerIdRequest request)
        {
            throw new NotImplementedException();
        }
    }
}

namespace CompanySourceSearch.ServiceImplement
{
    using CompanySourceSearch.Service.Contract;
    using CompanySourceSearch.ServiceDto.Response;
    using CompanySourceSearch.ServiceDto.Request;
    using CompanySourceSearch.ApplicationController.Interface; 

    public class SearchComputer : ISearchComputer
    {
        private readonly ISearchComputerApplicationController _searchComputerApplicationController; 

        public SearchComputer(ISearchComputerApplicationController searchComputerApplicationController)
        {
            this._searchComputerApplicationController = searchComputerApplicationController;
        } 

        public GetComputerByComputerIdResponse GetComputerByComputerId(GetComputerByComputerIdRequest request)
        {
            return _searchComputerApplicationController.GetComputerByComputerId(request);
        }
    }
} 

namespace CompanySourceSearch.Command.Interface
{
    using CompanySourceSearch.DomainModel; 

    public interface ISearchComputerTransactionCommand
    {
        List<Computer> FilterComputerResource(List<Computer> Computer);
    }
} 

namespace CompanySourceSearch.Command
{
    using CompanySourceSearch.Command.Interface; 

    public class SearchComputerTransactionCommand : CommandBase, ISearchComputerTransactionCommand
    {
        public List<DomainModel.Computer> FilterComputerResource(List<DomainModel.Computer> Computer)
        {
            throw new NotImplementedException();
        }
    }
} 

namespace CompanySourceSearch.ApplicationController
{
    using CompanySourceSearch.ApplicationController.Interface;
    using CompanySourceSearch.ServiceDto.Request;
    using CompanySourceSearch.ServiceDto.Response;
    using CompanySourceSearch.Command.Interface; 

    public class SearchComputerApplicationController : ISearchComputerApplicationController
    {
        private readonly ISearchComputerTransactionCommand _searchComputerTransactionCommand;
        public SearchComputerApplicationController(ISearchComputerTransactionCommand searchComputerTransactionCommand)
        {
            this._searchComputerTransactionCommand = searchComputerTransactionCommand;
        } 

        public GetComputerByComputerIdResponse GetComputerByComputerId(GetComputerByComputerIdRequest request)
        {
            throw new NotImplementedException();
        }
    }
} 

namespace CompanySourceSearch.Database.Interface
{
    using CompanySourceSearch.DatasourceDto; 

    public interface IComputerTableModule
    {
        List<ComputerDto> GetComputerById(long cId);
    }
} 

namespace CompanySourceSearch.ApplicationController
{
    using CompanySourceSearch.ApplicationController.Interface;
    using CompanySourceSearch.ServiceDto.Request;
    using CompanySourceSearch.ServiceDto.Response;
    using CompanySourceSearch.Command.Interface;
    using CompanySourceSearch.Database.Interface;
    using CompanySourceSearch.DatasourceDto;
    using CompanySourceSearch.Application.Common; 

    public class SearchComputerApplicationController : ISearchComputerApplicationController
    {
        private readonly ISearchComputerTransactionCommand _searchComputerTransactionCommand;
        private readonly IComputerTableModule _computerTableModule;
        public SearchComputerApplicationController(ISearchComputerTransactionCommand searchComputerTransactionCommand,
            IComputerTableModule computerTableModule)
        {
            this._searchComputerTransactionCommand = searchComputerTransactionCommand;
            this._computerTableModule = computerTableModule;
        } 

        public GetComputerByComputerIdResponse GetComputerByComputerId(GetComputerByComputerIdRequest request)
        {
            var result = new GetComputerByComputerIdResponse(); 

            var dbComputer = this._computerTableModule.GetComputerById(request.ComputerId);//从数据源中获取Computer集合
            var dominModel = dbComputer.ConvertToDomainModelFromDatasourceDto();//转换成DomainModel 

            var filetedModel = this._searchComputerTransactionCommand.FilterComputerResource(dominModel);//运行业务逻辑过滤 

            return result; 

        }
    }
}