走向.NET架构设计—第五章—业务层模式，原则，实践（前篇）

走向.NET架构设计—第五章—业务层模式，原则，实践（前篇）

　　前言：不管是GOF的23种设计模式，还是Flower的企业架构模式，相信很多的朋友知道或者听说过。在那些很经典的书中，对模式都做了很精辟的解释，本篇的目的在于看看这些模式如何应用在项目中的，并且给出一些代码的例子，小洋也希望大家能够真正的理解这些模式的思想，而不仅仅停留在代码结构和表面上。

  

本篇的议题如下：

架构模式

设计模式

设计原则

 

  

　　在上一章中，我们讲述了有关业务层分层的一些知识，下面我们就来看看，在具体的业务层的设计中，我们可以采用哪些模式可以将业务层设计的更加的灵活！

 

　　架构模式

　　首先我们就来看看，如何更加有效的组织业务规则。

 

　　Specification Pattern(需求规格模式)

 

　　这个模式的使用方法就是：把业务规则放在业务类的外面，并且封装成为一个个返回boolean值的算法。这些一个个的业务规则的算法不仅仅便于管理和维护，并且还可以被重用，而且很方便的组织成为复杂的业务逻辑。

 

　　下面我们就来看一个以在线租DVD的公司的例子。例子很简单，场景也很简单：判断一个用户是否可以租更多的DVD。下面就是我们设计的一个基本的类图。（大家肯定觉得一上来就看类图有点突兀，没有一步步的分析，其实我是想让大家知道，所讲的是个什么东西样子，之后大家再慢慢的理解）

　　下面我们就开始做这个事情：

 public interface ISpecification<T>
    {
        bool IsSatisfiedBy(T entity); 
    }

    public class HasReachedMaxSpecification : ISpecification<Customer>
{
        public bool IsSatisfiedBy(Customer entity)
        {
            return entity.TotalRentNumber > 5;
        }
}

复制代码

 

 　　上面的代码，其实就是把一个个的业务规则抽象出来了。我们知道，在系统中，不管业务规则多么复杂，最后在进行业务逻辑判定的时候，最后的结果还是“是否通过”。所以在这里就进行了抽象。

 

　　因为我们的例子是以一个在线租赁DVD为例子，用户可以来租赁DVD，其中也是有一定的规则的，例如，如果用户已经租了3盘DVD，那么我们就会考虑，这个用户时候还可以继续租DVD。至于根据什么判断：可能DVD公司规定一个人最多不能超过5盘，或者DVD公司认为某个用户的信誉不好等等。 

　　下面我们就来定义个具体的业务规则：HasReachedRentalThresholdSpecification

　　根据这个规则就决定一个用户是否可以租DVD。 　　

 

代码

 public class HasReachedRentalThresholdSpecification : ISpecification<CustomerAccount> 
    {
        public override bool IsSatisfiedBy(CustomerAccount candidate)
        {       
            return candidate.NumberOfRentalsThisMonth >= 5;        
        }
    }

  

　　这个规则定义出来后，我们就在业务类中使用这个规则：    

 

代码

public class Customer

{

        private ISpecification<Customer> specification = null;

        public Customer()

      {

            specification = new HasReachedMaxSpecification();

        }

 

        public int TotalRentNumber { get; set; }

 

        public bool CanRent()

        {

            return !specification.IsSatisfiedBy(this);

        }

}

  

　　当然，我们可以把更多的业务规则组合进来。

　　这个例子到这里就完了，这个例子中只是简单的采用了Specifiction模式。但是实际的情况往往是没有这个简单的，因为一个业务逻辑往往要组合多个多个业务规则。下面我们就来进一步的看：如果采用链式的结构来完成复杂的业务逻辑。

 

　　Composite Pattern（组合模式）

　　注：这个模式不属于架构模式，而且GOF模式的一种，这里列出来主要是为了配合之前的Specification模式的，大家不要在这里纠结这个问题 J

 

　　Composite模式允许把一个集合对象当做单个的对象来使用，而且我们还可以在这个所谓的”单个对象”中不断的嵌套。采用这种模式，可以把对象的层级关系组合成为“树形”的结构！我个人喜欢把它称为“容器模式”。

 

　　其实这个模式在我们在平时的ASP.NET或者WinForm ,WPF中到处可见。例如一个Panel控件，可以在里面加入另一个Panel,然后在Panel中可以加入GroupBox，然后再GroupBox中还可以加入Button等控件。这就是.NET Framework设计中采用了Compiste模式的例子。

 

　　下面来看看Compiste模式的UML结构图：

　　

 

　　

　　在上面的图中：
　　1. Component是一个抽象类，这个类提供了一个Add方法，这个Add可以加入其他的Component.大家想想，这样是否就可以很容易的实现链式的效果。

　　2. Leaf就是一个继承Component的具体类。

 

看到上面图，其实大家也可以想想在ASP.NET页面的生命周期中到处都是这种例子：例如在ASP.NET页面的Init事件中，因为Page本身就是一个容器，这个容器里面包含了很多的其他的控件，如Panel,Button，而且Panel里面还是控件。那么在Init方法就会调用自己的子容器的Init方法，然后子容器在调用自己的子容器的Init方法，这样就层层调用，直到最后调用到某个控件的Init的方法。这样这个页面的初始化就完成了。和上面的UML的结构是一样的。

 

下面我们还是来看一个例子吧。继续之前的Specification模式的讨论，看看如果结合则两种模式来组织复杂的业务逻辑。

为了使得例子有点说服力，我们把之前的业务稍微的变复杂一点点：为了判定一个用户是否可以租DVD，我们要进行一系列的规则判定之后才能决定结果：

1．    用户的账号是否处于激活的状态

2．    用户之前是否还欠费

3．    用户租赁DVD的数量是否达到了规定的数量

　　下面首先总体来看看一些类图的结构:

　　

 

不知道大家有没有注意一点：每次我在讲述一个功能的时候，总是先让大家看看总体的类图的设计，然后再开始一个个的讲述。其实这样做事有原因的。在之前的文章中，一直提到“设计Design”。就是说在做一个功能之前，不是一下子就砸进去编码，而是首先把功能考虑清楚，然后从总体上考虑功能如何实现，然后写出一些测试代码，最后写出一些实现代码的骨架。上面的类图其实就是一个骨架。

 按照之前的Specification模式的例子，我们首先条件两个类来新增的封装业务规则：

 

    现在我们将例子进行扩充：为了判定一个用户是否可以租DVD，我们要进行一系列的规则判定：

q 用户的账号是否处于激活的状态。

q 用户之前是否还欠费。

q 用户租赁DVD的数量是否达到了规定的数量。

代码

public class CustomerAccountStillActiveSpecification : ISpecification<CustomerAccount>  
    {
        public override bool IsSatisfiedBy(CustomerAccount candidate)
        {
            return candidate.AccountActive;
        }
    }

  

上面的代码用来判断用户是否处于激活状态

 

代码

    public class CustomerAccountHasLateFeesSpecification : ISpecification<CustomerAccount>  
    {
        public override bool IsSatisfiedBy(CustomerAccount candidate)
        {
            return candidate.LateFees > 0;
        }
    }

 

上面的代码就判断用户是否欠费 

添加完了所有的业务规则之后，好戏就开始了。

我们要把这些业务规则组合起来，放在容器中，然后只要调用父容器的一个方法，规则验证就一层层进行下去，就像我们之前举的ASP.NET的Init事件一样。

 

首先我们来添加一个表示容器的类：

 

代码

  public abstract class CompositeSpecification<T> : ISpecification<T>
    {
        public abstract bool IsSatisfiedBy(T candidate);

        public ISpecification<T> And(ISpecification<T> other)
        {
            return new AndSpecification<T>(this, other);
        }
      
        public ISpecification<T> Not()
        {
            return new NotSpecification<T>(this);
        }
    }

  

上面的代码有些不明白的地方，没什么，咱们耐心的往下面走。 

 

代码

public class AndSpecification<T> : CompositeSpecification<T>
    {
        private ISpecification<T> _leftSpecification;
        private ISpecification<T> _rightSpecification;

        public AndSpecification(ISpecification<T> leftSpecification, ISpecification<T> rightSpecification)
        {
            _leftSpecification = leftSpecification;
            _rightSpecification = rightSpecification;
        }

        public override bool IsSatisfiedBy(T candidate)
        {
            return _leftSpecification.IsSatisfiedBy(candidate) && _rightSpecification.IsSatisfiedBy(candidate);
        }
    }

 

代码

 public class NotSpecification<T> : CompositeSpecification<T>
    {
        private ISpecification<T> _innerSpecification;

        public NotSpecification(ISpecification<T> innerSpecification)
        {
            _innerSpecification = innerSpecification;
        }

        public override bool IsSatisfiedBy(T candidate)
        {
            return !_innerSpecification.IsSatisfiedBy(candidate);
        }
    }

  

上面基础代码完成了，我们就开始实现我们想要的链式的效果！

我们修改之前的几个规则，和接口的定义，如下：

 

代码

public class HasReachedRentalThresholdSpecification :CompositeSpecification<CustomerAccount>
{
        …
}

public class CustomerAccountStillActiveSpecification :CompositeSpecification<CustomerAccount>
{

       …
}

public class CustomerAccountHasLateFeesSpecification :CompositeSpecification<CustomerAccount>
{
      …
}

  

漫长的过程终于结束了，到了核心的部分，请看业务类现在的定义：

 

public class Customer
{
         private ISpecification<Customer> hasReachedRentalThreshold;
        private ISpecification<Customer> customerIsActive;
        private ISpecification<Customer> customerHasLateFees;

        public Customer()
        {
          hasReachedRentalThreshold = new HasReachedMaxSpecification();
            customerIsActive = new CustomerAvtiveSpecification();
            customerHasLateFees = new CustomerHasLateFeesSpecification();
        }

        public decimal TotalRentNumber { get; set; }
        public bool IsActive { get; set; }
        public decimal LateFees { get; set; }

        public bool CanRent()
        {
            ISpecification<Customer>canRent =customerIsActive.And(hasReachedRentalThreshold.Not()).And(customerHasLateFees.Not());
            return canRent.IsSatisfiedBy(this);
        }
}

复制代码

大家主要看看那个 CanRent方法

下面我们就来讲讲这个方法。

customerAccountActive继承自CompositeSpecification,而Add方法的定义如下：

 

public ISpecification<T> And(ISpecification<T> other)
{
     return new AndSpecification<T>(this, other);
}

复制代码

  

　　_customerAccountIsActive.And(_hasReachedRentalThreshold.Not())的结果就是使得customerAccountIsActive内部包含了平行的两条业务规则，结构如下：

 

 

 

　　方法返回的结果还是一个实现了ISpecification的对象，只不过这个对象（我们称之为“容器A”）里面有两个规则了。

　　然后这个保量两个业务规则的对象（容器A）再次调用Add方法，如下：

 

　　_customerAccountIsActive.And(_hasReachedRentalThreshold.Not()).
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　And(_customerAccountHasLateFees.Not());

复制代码

 

　　此时相当于把之前那个容器A作为一个单独对象，再次调用Add方法，于是这个三个规则组合成为一个大的规则的容器：如下。

 

 

　　今天就到这里，东西不多，大家多琢磨一下！

• 赞
• 收藏
• 评论
• 分享
• 举报

上一篇：走向.NET架构设计—第四章—业务层分层架构（后篇）

下一篇：走向.NET架构设计—第五章—业务层模式，原则，实践（中篇）

提问和评论都可以，用心的回复会被更多人看到 评论

发布评论

全部评论 () 最热 最新

相关文章

• 【操作系统】第五章 存储管理

  处理器可以直接访问内存，但是不能直接访问外存。只有通过I/O设备才可以将外存装入内存或者反过来。但是固态硬盘即可直接访问，又可以掉电后保存信息但是写入速率与CPU不匹配，通常也还是作为外存使用。第一节 概述最理想的存储：高速、海量、非易失；实际上它们无法同时具有。因此，需要组合分层。一、存储体系目前最先进的存储部件仍明显慢于同级别CPU的速度；而且成本方面，任何一种存储部件都无法在速度与容量两方面

  存储体系 分区管理 虚拟存储 页面替换算法 夏明亮
• 第五章 游戏开发Tiled篇-Tiled正常方向（Orthogonal）地图编辑——绘制图块层

  本文围绕游戏开发中 Tiled 的正常方向地图编辑展开，首先介绍了新建正交地图和图块集的方法，接着详细阐述了绘制地图的各类图块层工具，包括图章刷、地形刷、填充工具等及其工具扩展的功能和使用方式，最后通过示例展示了用图块层工具在多个图层绘制以实现元素遮挡、使画面更真实的过程。

  游戏开发 图块层
• 【离散数学】第五章 关系与函数(1)

  关系是集合元素之间存在的某种关联性。5.1 关系及关系的性质定义5.1 设A，B两个集合，的子集R称为从A到B的二元关系。特别地，当A=B时，称R为A上的关系。如果，可记作，称x与y有关系R；如果，则记作；称x与y没有关系R。显然A到B的二元关系也是有序对集合。但是它与笛卡儿积是不同的；关系可能仅在两个集合的部分元素之间有定义，没有定义的元素之间不存在关系。而笛卡儿积是两个集合全部元素之间都有定义

  二元关系 元组 笛卡儿积
• 走向.NET架构设计—第五章—业务层模式，原则，实践（后篇）

  走向.NET架构设计—第五章—业务层模式，原则，实践（后篇） 　　前言：在上一篇文章中，讲述了一些设计模式的使用，本篇首先接着介绍还没有讲完的一些设计模式，然后再讲述一些架构模式中的超类模式，作为本篇的结尾。 本篇的议题如下：架构模式         设计模式  &

  设计模式 State 燕洋天 架构模式 .NET架构设计
• 走向.NET架构设计—第五章—业务层模式，原则，实践（中篇）

  走向.NET架构设计—第五章—业务层模式，原则，实践（中篇） 　　前言：设计模式并不是什么很高深的东西，至少不是那么“神乎其神”。说到底，设计模式就是一些设计思想。下面我们就走进项目，看看这些项目中这些思想是如何体现的。本系列文章会在后续文章中陆陆续续的，在恰当的时候介绍一些相应的设计模式，而不是一股脑的一起上。 本篇的议题如下：架构模式设计模式设计原则&nb

  设计模式 小洋 燕洋天 架构模式 .NET架构设计
• 走向.NET架构设计—第四章—业务层分层架构（前篇）

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

  分层 DDD 小洋 燕洋天 .NET架构设计
• 大话设计模式--第五章 依赖倒置原则

  依赖倒置原则 所谓的依赖倒置原则 A.针对接口编程, 不要针对实现编程 B.高层模块不应该依赖于底层模块, 两个都应该依赖于抽象 依赖倒置原则: 原话解释的是, 抽象不应该依赖于细节, 细节应该依赖于抽象. 说白了, 就是上面那句话。针对接口编程， 不要针对实现编程。 以计算机为例。无论是主板， 还

  设计模式
• 第五章 传输层

  TCP 传输控制协议 需要将要传输的文件分段 传输 建立会话 可靠传输 流量控制 UDP 用户数据报协议 一个数据包就能够完成数据通信 不需要建立会话 不需要流量控制 不可靠传输 屏幕广播(虽然一个包传不完但还是UDP协议,因为不需要保证可靠性,不需要建立会话) 多播,广播 传输层协议和应用层协议之 Read More

  服务器 端口号 数据 传输层 首部
• 《微服务架构设计模式》第五章 微服务架构中的业务逻辑设计

  在领域驱动设计的上下文中，领域事件是聚合发生的事情。它由领域模型中的一个类表示。事件通常代表状态的变化。

  架构 微服务 java 业务逻辑 领域模型
• 走向.NET架构设计—第四章—业务层分层架构（后篇）

  走向.NET架构设计—第四章—业务层分层架构（后篇）　　前言： 在上一篇文章中，我们讨论了组织业务逻辑的模式：Transaction Script和Active Record，Domain Model。在本篇中开始讲述Anemic Model。     今天的内容比较简单，也是本章的一个收尾！ 本篇议题如下：Tra

  分层 业务层 小洋 燕洋天 .NET架构设计
• 第五章 实践者

  第五章 实践者 我们经常会在街上看到一个地方围了一群人，为了凑凑热闹，走过去一看，原来是个哑巴在卖刀。我们一般对销售人员的要求是能说会道，口齿伶俐，但这哑巴如何说得？这刀又如何买得？哑巴一声不吭（他出声别人也听不懂），只见他一手拿着刀，一手拿着个铁丝，把铁丝砍得一节一节的，然后再把菜刀拿给大家看，那菜刀自是“毫发无损”。这铁丝都切得，如何能切不动肉呢？还有的时候，这个人群里面也许不是一个哑

  职场 实践者 休闲
• 网络__第五章 运输层

  1.运输层的功能和服务 2.运输层的SAP：端口 3.UDP协议：报文格式、工作原理 4.TCP协议： n报文格式 nTCP的可靠传输机制 n序号与确认 n流量控制 n拥塞控制 n连接管理 &#160; 二、运输层的地位和作用 1.位置：面向通信功能的最高层，用户功能的最地层，仅存在于用户主机中。 ● 作用：基于网络层提供的主机数据通信服务，在网络边缘的主机之间提供可靠

  网络 通信 工作原理 用户 流量
• 走向.NET架构设计—第四章—业务层分层架构（中篇续篇）

  走向.NET架构设计—第四章—业务层分层架构（中篇）　　前言： 在上一篇文章中，我们讨论了两种组织业务逻辑的模式：Transaction Script和Active Record。在本篇中开始讲述Domain Model和Anemic Model。      注：不管技术的道路多么难走，我们还是得踏踏实实的把技术做下去。也希望朋友们能够一如

  分层 DDD 小洋 燕洋天 .NET架构设计
• 第五章

  wifi_hotspot.h接口简介:这个wifi_hotspot.h中包含声明AP热点相关接口函数。打开“D1_iot_wifi_ap”工程的wifi_ap.c文件，可在代码中查看实现创建Wifi热点的代码wifi_device.h接口简介:这个wifi_device.h中包含声明AP热点相关接口函数。打开“D2_iot_wifi_sta_connect”工程的wifi_sta_connect.

  wifi热点
• 第五章 传输层协议介绍

  TCP协议介绍tcp/ip协议族的传输层协议 tcp（Transmission Control Protocol） 传输控制协议UDP(User Datagram Protocol) 用户数据报协议TCP协议面向连接网络协议,是指通信双方之间在进行通信之前要先建立连接。比如打电话,双方通话前需要先建立连接。等数据发送结束后,双方再断开连接。无连接网络协议,是指通信双方

  客户端 数据 服务器
• 一起谈.NET技术，走向ASP.NET架构设计——第五章：业务层模式，原则，实践（前篇）

  在上一章中，我们讲述了有关业务层分层的一些知识，下面我们就来看看，在具体的业务层的设计中，我们可以采用哪些模式可以将业务层设计的更加的灵活！ 架构模式 首先我们就来看看，如何更加有效的组织业务规则。 Specification Pattern(需求规格模式) 这个模式的使用方法就是：把业务规则放在业务类的外面，并且封装成为一个个返回boolean值的算法。这些一个个的业务规则的算法不仅仅便于管理和维护，并且还可以被重用，而且很方便的组织成为复杂的业务逻辑。 下面我们就来看一个以在线租DVD的公司的例子。例子很简单，场景也很简单：判断一个用户是否可以租更多的DVD。下面就...

  类图 ide 业务逻辑 控件 asp.net
• 一起谈.NET技术，走向ASP.NET架构设计——第五章：业务层模式，原则，实践（中篇）

  前言：设计模式并不是什么很高深的东西，至少不是那么“神乎其神”。说到底，设计模式就是一些设计思想。下面我们就走进项目，看看这些项目中这些思想是如何体现的。本系列文章会在后续文章中陆陆续续的，在恰当的时候介绍一些相应的设计模式，而不是一股脑的一起上。 设计模式 本篇文章主要是讨论的在业务层可以采用的或者常用的一些设计模式： Factory Method相信很多朋友对这个模式很熟悉了，平时在项目中或多或少总能看到Factory, Provider等。确实Factory Method一种创建型的模式，它的主要目的就是隐藏对象创建的细节。也就是说，客户程序（或者成为调用者）不用特定...

  设计模式 抽象类 解决方案 值对象 购物网站
• 一起谈.NET技术，走向ASP.NET架构设计——第五章：业务层模式，原则，实践（后篇）

  设计模式 本篇文章主要是接着讨论的在业务层可以采用的或者常用的一些设计模式： State模式 状态模式允许一个对象在随着它的状态变化而改变它自身的一些行为。 在项目开发的过程中，有一些类，例如一个业务类常常是有自己的一些状态的，而且还存在状态之间的一些转换，有些状态之间是可以进行转换的，有些状态之间是不能转换的。就拿一个汽车来举例子，汽车有很多的状态：静止，启动，前进，后退，停车。而且不能由”前进”状态转为“启动”状态。 很多朋友知道state模式的用法和结构，朋友们应该也清楚在状态之间的转换用swtich.. case的一些弊端。在项目中，很多时候就没有”一定”,”非...

  超类 ide 策略模式 唯一标识 设计模式
• 第五章 模式匹配

  第五章 模式匹配\b 匹配一个字符边界\t 匹配一个普通水平制表字符/bar{3}/ 匹配的是barrr5.2 模式匹配操作符:m// 用于匹配一个模式,s///用于将某个符合模式的子字符窜代换为某个子串每...

  perl oracle 操作符 子模式 换行符
• 一起谈.NET技术，走向ASP.NET架构设计——第四章：业务层分层架构（前篇）

  在讨论完四种模式之后，我将会和大家一起来看看DDD的一些知识。每种模式的讲解，我都会用实例的形式给出完整的代码，也希望大家多琢磨！ 不是所有的应用程序都是一样的，也不是所有的系统都需要用复杂的架构来组织业务逻辑。作为开发人员，我们必须清楚每一种业务逻辑组织的模式，这样我们才能在需要的时候做出合适的选择。 Transaction Script 这种组织业务逻辑的模式是最简单，也是最容易理解的。Transaction Script模式就是用面向过程的方式来组织业务逻辑的。通常情况下，系统的一个流程就被实现为一个方法，然后把所有的这些方法组织在一起，放在一个静态的manager类或者...

  业务逻辑 数据库 mvc 面向过程 数据