走向.NET架构设计—第四章—业务层分层架构（前篇）

走向.NET架构设计—第四章—业务层分层架构（前篇）

　　前言：在任何一个项目中业务层毫无疑问是最重要的层，所以在设计的过程中，如何组织业务层是至关重要的。本章的讨论将会涉及Flower的架构模式一书中的四种组织业务层的模式：Transaction Sript,Active Record,Anemic Model 和Domain Model。每一中组织业务逻辑的模式有着各自都优缺点，如何选择他们重要的还是取决于我们所要开发的项目的类型。

在讨论完四种模式之后，我将会和大家一起来看看DDD的一些知识。

每种模式的讲解，我都会用实例的形式给出完整的代码，也希望大家多琢磨！

本篇议题如下：

Transaction Scrip(前篇)

Active Record前篇)

Domain Model（中篇）

Anemic Model（中篇）

DDD（后篇）

　　不是所有的应用程序都是一样的，也不是所有的系统都需要用复杂的架构来组织业务逻辑。作为开发人员，我们必须清楚每一种业务逻辑组织的模式，这样我们才能在需要的时候做出合适的选择。

　　Transaction Script

这种组织业务逻辑的模式是最简单，也是最容易理解的。Transaction Script模式就是用面向过程的方式来组织业务逻辑的。通常情况下，系统的一个流程就被实现为一个方法，然后把所有的这些方法组织在一起，放在一个静态的manager类或者service 类中。实现流程的那个方法包含了业务逻辑的Check和Validation，数据的持久化以及其他的一些相关操作。也就是说，一个方法把所有的事情都做完了。当然，有时候这个大的方法还可能被拆成小的方法，便于重用。

Transaction Script一个好处就是理解起来很简单，尤其是当Team中的一个新成员来说，更是如此，因为他几乎不用花什么时间，就能立刻明白这种组织业务逻辑的方式。每当来了一个新的需求的时候，要做的事情就是去加上一个或者一些新的方法来是实现这个需求，而其还不会影响其他已经存在的功能。

对于一个很小的或者基本山没什么业务逻辑的系统来说，用Transaction Script模式组织业务逻辑还是很不错的，而且对一个刚刚踏入IT的开发人员门槛也比较低。：当系统开始变大，业务逻辑开始变得复杂的时候Transaction Script的问题的出来了。最后的结果可能就是系统中存在大量的方法，而且这些方法中到处都是重复的代码。有的时候，我们可以提炼出一些业务逻辑的验证代码组织为方法，但是我们去很难提炼出一些在流程上相识的代码，即使两个流程只有一点点的不同。如果系统的需求稍微一边，导致流程变了一点点，那么很多的方法就要改动，而且我们还得在系统中去找出那些相似的流程代码，然后修改，万一哪个方法没有找出，后果可想而知。

下面我们就用一个人事请假管理系统为例子来看看Transaction Script是如何实现的。因为Transaction Script很简单，所以下面的代码也只是用于演示，大家理解就行了。

代码

public class HolidayService
{
      public static bool BookHolidayFor(int employeeId, DateTime From, DateTime To)
      {
          bool booked = false;
          TimeSpan numberOfDaysRequestedForHoliday = To - From;
          if (numberOfDaysRequestedForHoliday.Days > 0)
            {
              if (RequestHolidayDoesNotClashWithExistingHoliday(employeeId, From, To))
                {
                    int holidayAvailable = GetHolidayRemainingFor(employeeId);
                    if (holidayAvailable >= numberOfDaysRequestedForHoliday.Days)
                    {
                        SubmitHolidayBookingFor(employeeId, From, To);
                        booked = true;
                    }
                }
            }
            return booked;
        }

private static int GetHolidayRemainingFor(int employeeId)
        {
            // ...
        }

public static List<EmployeeDTO> GetAllEmployeesOnLeaveBetween(
        DateTime From, DateTime To)
        {
            // ...
        }

public static List<EmployeeDTO> GetAllEmployeesWithHolidayRemaining()
        {
            // ...
        }
    }

一眼看上去，我们就很容易理解这种面向过程的方式：系统中的所有的用例都被组织成了一个个的方法。例如在BookHolidayFor方法中就做了很多的事情：查询和持久化数据，是否允许请教的业务逻辑的实现等。

如果在一个很简单的，业务很少的系统中采用这种方式还是可以的，随着业务逻辑的越来越复杂，我们就得重新考虑下这种组织逻辑的方式，越早发现，越早做出改变，以后的成本将会越小。

　　Active Record

下面就以一个内容管理系统中的文章管理功能为例来讲述如何使用活动记录模式来组织业务逻辑。相信大家对内容管理管理系统（CMS）都有一些了解，对于文章模块，用户可以发布文章，游客或其他用户可以发表评论。在相应的数据库中，存在着文章表tb_Articles和评论表tb_Comments，

在Active Record模式中，每一个业务对象各自负责自己的数据持久化逻辑和相关的业务逻辑。正如前面提到的：Active Record模式很适合那种“业务对象和数据表一一对应”的简单的应用程序，例如Blog，Forum等系统。因为在Active Record模式中，每一个业务类和表都有对应的关系，而且业务类都包含了CRUD的操作，那么我们可以使用一些代码生成工具来加速我们的开发，而且有些好的代码生成工具还包含了一些数据库的逻辑验证代码来确保我们把正确的数据保存到数据库中。

下面我们就用一个例子来看看这种模式是如何应用的。例子还是采用之前谈到的CMS Blog系统。

在业务层，业务类Article和Comment的结构如图所示

在Active Record模式中，每一个业务对象各自负责自己的数据持久化逻辑和相关的业务逻辑。

正如前面提到的：Active Record模式很适合“业务对象和数据表一一对应”的应用程序，例如Blog、Forum等系统；同时Active Record模式也比较适合“数据为先”的应用程序：根据现有的数据库来组织逻辑和建立业务模型。

因为在Active Record模式中，每一个业务类和表都有对应的关系，而且业务类都包含了CRUD的操作，我们可以使用一些代码生成工具来加速开发，而且有些好的代码生成工具还包含了一些数据库的逻辑验证代码，以确保我们把正确的数据保存到数据库中。例如，在.NET中，可以直接使用Castle 的Active Record Framework来快速开发应用程序。

下面就使用Castle ActiveRecord框架来开发上面的文章管理模块

[ActiveRecord("tb_Comments")]
    public class Comment : ActiveRecordBase<Comment>
    {
        [PrimaryKey]
        public int Id { get; set; }

[BelongsTo("ArticleID")]
public Article Post { get; set; }

[Property]
public string Subject { get; set; }

[Property]
public string Content { get; set; }

[Property]
public DateTime CreatedDate { get; set; }

[Property]
public string CreatedBy { get; set; }

[Property]
public DateTime UpdatedDate { get; set; }
}

复制代码

上面的代码可以看成类似ORM的映射过程：在Comment类加上Attribute，表明这个属性和数据表中同名的列对应（在Castle.ActiveRecord框架内部也采用了NHibernate，所以，上面实际上就是NHibernate的映射）。

从上面的一些工作量可以看出，用相应的Frameword来实现blog系统还是比较的快的。而且上面的例子中，业务类和表的结构很一致，这也是Active Record的特点和优势。但是如果业务类和数据表的结构不一致，而且逻辑也变复杂了，也就是出现了“抗阻不匹配”。如果还在这中模式上面坚持，会使后面的开始过程和代码维护变得困难，那么我们就得采用Domain Model模式来组织业务逻辑。

上面的例子讲的很粗糙，因为上面的两种模式本身还是比较容易理解的，到了Domain Model模式的讲解的时候，会更加的详细。

今天就到这里了，还是希望多多见谅，支持！谢谢啊！

转载于:https://blog.51cto.com/yanyangtian/413312

走向.NET架构设计—第四章—业务层分层架构（前篇）相关推荐

走向.NET架构设计—第四章—业务层分层架构（后篇）
走向.NET架构设计-第四章-业务层分层架构(后篇) 前言: 在上一篇文章中,我们讨论了组织业务逻辑的模式:Transaction Script和Active Record,Domain Model. ...
走向.NET架构设计—第四章—业务层分层架构（中篇）
走向.NET架构设计-第四章-业务层分层架构(中篇) 前言: 在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Dom ...
走向.NET架构设计—第五章—业务层模式，原则，实践（中篇）
走向.NET架构设计-第五章-业务层模式,原则,实践(中篇) 前言:设计模式并不是什么很高深的东西,至少不是那么"神乎其神".说到底,设计模式就是一些设计思想.下面我们就走进项目, ...
走向.NET架构设计—第五章—业务层模式，原则，实践（后篇）
走向.NET架构设计-第五章-业务层模式,原则,实践(后篇) 前言:在上一篇文章中,讲述了一些设计模式的使用,本篇首先接着介绍还没有讲完的一些设计模式,然后再讲述一些架构模式中的超类模式,作为本篇的结 ...
走向ASP.NET架构设计-第六章-服务层设计(中篇)
走向ASP.NET架构设计-第六章-服务层设计(中篇) 前言:上一篇文章介绍了一些服务层的基本知识,而且也简要的介绍了SOA的有关知识,本篇主要是介绍在服务层可以采用的一些模式. 本篇议题如下: F ...
走向.NET架构设计—第三章—分层设计，初涉架构(后篇)
走向.NET架构设计-第三章-分层设计,初涉架构(后篇) 前言:本篇主要是接着前两篇文章继续讲述! 本篇的议题如下: 4．数据访问层设计 5．显示层设计 6． UI层设计 4．数据访问层设 ...
微服务架构设计实践之七：业务架构
微服务架构设计实践之七:业务架构原文:微服务架构设计实践之七:业务架构版权声明: https://blog.csdn.net/beyondself_77/article/details/79842 ...
超标量处理器设计——第四章_分支预测
超标量处理器设计--第四章_分支预测参考<超标量处理器>姚永斌著 4.1 简述分支预测主要与预测两个内容, 一个是分支方向, 还有一个是跳转的目标地址首先需要识别出取出的指令是否是分 ...
DDD微服务架构设计第四课微服务落地实践的技术中台
10 微服务落地的技术实践如今,做一个优秀的程序员越来越难.激烈的市场竞争.互联网快速的迭代.软件系统规模化发展,无疑都大大增加了软件设计的难度.因此,对于架构师的能力要求也越来越高,就像我的一本书 ...

走向.NET架构设计—第四章—业务层分层架构（前篇）

走向.NET架构设计—第四章—业务层分层架构（前篇）相关推荐

最新文章

热门文章