走向.NET架构设计—第五章—业务层模式，原则，实践（后篇）-低调大师

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

2017-11-08 512

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

　　前言：在上一篇文章中，讲述了一些设计模式的使用，本篇首先接着介绍还没有讲完的一些设计模式，然后再讲述一些架构模式中的超类模式，作为本篇的结尾。

本篇的议题如下：

架构模式

设计模式

设计原则

　　设计模式

　　本篇文章主要是接着讨论的在业务层可以采用的或者常用的一些设计模式：

　　Factory Method

　　Decorator

　　State

　　Strategy

　　State 模式

　　状态模式允许一个对象在随着它的状态变化而改变它自身的一些行为。

在项目开发的过程中，有一些类，例如一个业务类常常是有自己的一些状态的，而且还存在状态之间的一些转换，有些状态之间是可以进行转换的，有些状态之间是不能转换的。就拿一个汽车来举例子，汽车有很多的状态：静止，启动，前进，后退，停车。而且不能由 ” 前进 ” 状态转为“启动”状态。

很多朋友知道 state 模式的用法和结构，朋友们应该也清楚在状态之间的转换用 swtich.. case 的一些弊端。在项目中，很多时候就没有 ” 一定 ”,” 非得 ” 要用 state 模式来解决类似的问题，即使可以用 state 模式来解决。如果变化不大， switch.. case 就够用了。

下面还是来首先来看看使用 state 模式的一些例子。

还是采用电子商务为背景来举例：每一个订单都是有状态的： New （新的） ,Shipped （已经发货）， Canceled( 已取消 ) 。我们知道一个新的订单可以被变为 ” 取消 ” 的状态，也可以成为 ” 已发货 ” 状态。但是订单不能从 ” 已发货 ” 状态，变为 ” 取消 ” 的状态。

　下面就是例子中的类图：

　　首先还是创建一个名为 :ASPPatterns.Chap5.StatePattern 的解决方案，添加一个名为 :ASPPattern.Chap5.StatePattern.Model 的类库：

　　然后添加在 Model 的类库中添加一个表示状态接口的定义： IOrderState:

代码

public interface IOrderState
    {
         bool CanShip(Order Order);
         void Ship(Order Order);

         bool CanCancel(Order Order);
         void Cancel(Order order);

        OrderStatus Status { get ; }
    }

下面来定义个表示订单状态的枚举：

public enum OrderStatus
    {
       New = 0 ,
       Shipped = 1 ,
       Canceled = 2
    }

然后我们来看看，真正要进行状态转化的那个订单类：

代码

public class Order
    {
         private IOrderState _orderState;

         public Order(IOrderState baseState)
        {
            _orderState = baseState;
        }

         public int Id { get ; set ; }

         public string Customer { get ; set ; }

         public DateTime OrderedDate { get ; set ; }

         public OrderStatus Status()
        {
             return _orderState.Status;
        }

         public bool CanCancel()
        {
             return _orderState.CanCancel( this );
        }

         public void Cancel()
        {
             if (CanCancel())
                _orderState.Cancel( this );
        }

         public bool CanShip()
        {
             return _orderState.CanShip( this );
        }

         public void Ship()
        {
             if (CanShip())
                _orderState.Ship( this );
        }

         internal void Change(IOrderState OrderState)
        {
            _orderState = OrderState;
        }
    }

其实状态模式一个最主要的思想就是：把状态之间的转换分离出来，把每一个状态分解为一个个的状态的类，然后这些状态来负责如何在不同的状态之间的转换。也就是说，就本例而言，以前我们会在 Order 类中写上如下的语句：

代码

public void ChangeStatus()
        {
             switch (Status)
            {
                 case OrderStatus.New:
                     // .... do some things
                     break ;
                 case OrderStatus.Shipped:
                     // .... do some things
                     break ;

                 case OrderStatus.Canceled:
                     // .... do some things
                     break ;
            }
        }

我们知道其实此时就是由 Order 类来控制了状态之间的转换。其实 state 模式的就是让那些“状态”变为一个“有思想”的状态类，这些类自己来负责如何以及何时转换到其他的状态，这样 Order 的“负担”就减轻了。还有一个就是大家常常会 ” 批判 ” ：如何要添加一个新的状态，那么 ChangeStatus 方法势必会变化，因为这个方法控制了状态之间的转换，如果把状态的转换逻辑分离出去，最好做到添加或者减少状态都不会影响现有的 Order 就更好了。

下面的讲述有点直接，希望不熟悉 state 模式的朋友先“撑下去” J

1. 当创建一个订单的时。候，这个订单的状态肯定就是 ”New”( 新的 ) 。那么我们可能就传入一个表示“ New ”状态的类： OrderNewStatus:

new Order(OrderNewState newStatus)

OrderNewStatus 把订单的状态标记为 New

我们知道：订单的状态为 New 的时候，状态可以向 Canceled 和 Shipped 转换，那么 OrderNewStatus 的定义可能如下：

代码

public class OrderNewState : IOrderState
    {
         public bool CanShip(Order Order)
        {
             return true ;
        }

         public void Ship(Order Order)
        {
            Order.Change( new OrderShippedState());
        }

         public OrderStatus Status
        {
             get { return OrderStatus.New; }
        }

         public bool CanCancel(Order Order)
        {
             return true ;
        }

         public void Cancel(Order order)
        {
            order.Change( new OrderCanceledState());
        }

         public new Order(OrderNewState newStatus);

    }

2. 当新创建的订单处理到一定的流程的时候，例如要发货了，此时要更新订单的状态，此时我们只要调用 Order 的 ship 方法就行了。其实此时我们就是在调用 NewOrderStatus 类的 Ship 方法，这个类的 ship 方法知道怎么做：先判断 Order 的是否可以向 Shipped 状态转换 ( 调用 CanShip 方法 ) ，如果可以，那么就 new 一个 OrderShippedStatus 状态的类，然后用这个类去替换原来的 NewOrderStatus( 调用 Order 类的 Change 方法 ) ，这样， Order 的状态就是 Shipped 了，但是 Order 完全不用管状态之间是如何变化的。

代码

     public class OrderShippedState : IOrderState
    {
         public bool CanShip(Order order)
        {
             return false ;
        }

         public void Ship(Order order)
        {
             throw new NotImplementedException( " You can't ship a shipped order! " );
        }

         public OrderStatus Status
        {
             get { return OrderStatus.Shipped; }
        }

         public bool CanCancel(Order Order)
        {
             return false ;
        }

         public void Cancel(Order order)
        {
             throw new NotImplementedException( " You can't ship a shipped order! " );
        }

    }

3. Canceled 状态也同理，我这里就不在赘述了。

代码

public class OrderCanceledState : IOrderState
    {
         public bool CanShip(Order Order)
        {
             return false ;
        }

         public void Ship(Order Order)
        {
             throw new NotImplementedException( " You can't ship a cancelled order! " );
        }

         public OrderStatus Status
        {
             get { return OrderStatus.Canceled; }
        }

         public bool CanCancel(Order Order)
        {
             return false ;
        }

         public void Cancel(Order order)
        {
             throw new NotImplementedException( " You can't ship a cancelled order! " );
        }
    }

我们用一个 UML 图来结束 state 模式的讲述：

Strategy模式

其实策略模式，我这里不打算作太多的讲述，其实这种模式大家到处可见，我们常常在 ASP.NET 中常常提起的 Provider 模式，其实就是策略模式的一种实现。

大家看看结构图，基本上就明白了：

在上述的图中 Context 依赖一个 IStrategy 接口，我们可以决定让 Context 使用 IStrategy 的任意的一个实现者： ConcreteStrategyA 或者 ConcreteStrategyB 。其实就是可以替换不同的实现者。可能大家在数据访问层那块有的体验更加的明显：定义一个 IDataProvider ，然后实现一个 AdoDotNetProvider 和一个 LinqToSqlProvider 。

架构模式

下面就来补充一些架构模式的知识，下文主要讲述： Layer Supertype 模式（超类模式）

超类模式就是定义一个基类，然后其他的所有的类都从这个类中继承。对于业务层而言，在超类中可能会定义一些通用的业务规则和验证方法，这样就这些代码被到处分散。也体现了继承的一个好处。

下面我们就来看一个项目中的例子（电子商务为例），类结构如下：

大家可以看到，所有的业务类都是从 EntityBase 继承的。

代码

   public abstract class EntityBase < T >
    {
         private T _Id;
         private bool _idHasBeenSet = false ;
         private IList < string > _brokenRules = new List < string > ();

         public EntityBase()
        { }

         public EntityBase(T Id)
        {
             this .Id = Id;
        }

         public T Id
        {
             get { return _Id; }
             set
            {
                 if (_idHasBeenSet)
                    ThrowExceptionIfOverwritingAnId();

                _Id = value;
                _idHasBeenSet = true ;
            }
        }

         private void ThrowExceptionIfOverwritingAnId()
        {
             throw new ApplicationException( " You cannot change the id of an entity. " );
        }

         public bool IsValid()
        {
            ClearCollectionOfBrokenRules();
            CheckForBrokenRules();
             return _brokenRules.Count() == 0 ;
        }

         protected abstract void CheckForBrokenRules();

         private void ClearCollectionOfBrokenRules()
        {
            _brokenRules.Clear();
        }

         public IEnumerable < string > GetBrokenBusinessRules()
        {
             return _brokenRules;
        }

         protected void AddBrokenRule( string brokenRule)
        {
            _brokenRules.Add(brokenRule);
        }
    }

在这个超类中，提供了保存每个业务类唯一标识的逻辑，并且确保这个标识一旦设定就不会被改变。而且这个超类还提供一些简单的验证逻辑。

我们再来看看如何使用这个超类，下面定义了一个 Customer 的业务类：

代码

   public class Customer : EntityBase < long >
    {
         public Customer() { }

         public Customer( long Id)
            : base (Id)
        { }

         public string FirstName { get ; set ; }
         public string LastName { get ; set ; }

         protected override void CheckForBrokenRules()
        {
             if (String.IsNullOrEmpty(FirstName))
                 base .AddBrokenRule( " You must supply a first name. " );

             if (String.IsNullOrEmpty(LastName))
                 base .AddBrokenRule( " You must supply a last name. " );
        }
    }

在这个类中，我们定义了唯一标识的类型 :long ，而且还定义了一些业务规则： FirstName, LastName 不为空。至于如何调用这些验证规则，在超类中已经实现了，此时业务类就“轻松”了很多 — 起码不用再次写那些相类似的代码了，实现了一定程度上的代码重用。

今天就讲到这里了，不正确之处，还望朋友们指出，见谅！

多谢支持！

本文转自yanyangtian51CTO博客，原文链接： http://blog.51cto.com/yanyangtian/434979 ，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/465139

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

《卓有成效的管理者》培训分享——来自项目管理群的讨论

20110719 小醉《卓有成效的管理者》培训分享谷雨霖-cto-北京新浪微博ID：冯国馨PMBAR说: 今天中午13：00-14:00，PMBAR专题分享主题是：第83期7.19的主题：《卓有成效的管理者》不胜人生一场醉-架构师-damn bj 超-技术负责-深圳说: 期待队队-PMO主管-北京说: 等候马兆林-cio-京说: 先呱唧呱唧不胜人生一场醉-架构师-damn bj[新浪微博ID：不胜人生一场醉_]说: hi lastwinner-pm-bj说: 列队欢迎！ Lwantstudy-PMO-DaLian说: 欢迎！ SUPER_DEV_北京说: 鼓掌 Wucm–PM–上海说: 不胜人生一场醉-架构师-damn bj[新浪微博ID：不胜人生一场醉_]说: 其实没做啥准备，欢迎随时打断交流啊谷雨霖-cto-北京新浪微博ID：冯国馨PMBAR说: up 不胜人生一场醉-架构师-damn bj[新浪微博ID：不胜人生一场醉_]说: 2011年7月1日-7月2日参加了公司组织的《卓有成效的管理者》培训。其实培训老师讲的很一般，差点都要换掉他了不胜人生一场醉-架构师-...

2017-11-09

470

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

走向.NET架构设计—第五章—业务层模式，原则，实践（中篇）前言：设计模式并不是什么很高深的东西，至少不是那么“神乎其神”。说到底，设计模式就是一些设计思想。下面我们就走进项目，看看这些项目中这些思想是如何体现的。本系列文章会在后续文章中陆陆续续的，在恰当的时候介绍一些相应的设计模式，而不是一股脑的一起上。本篇的议题如下：架构模式设计模式设计原则　设计模式本篇文章主要是讨论的在业务层可以采用的或者常用的一些设计模式： Factory Method Decorator Template Method State Strategy Factory Method 相信很多朋友对这个模式很熟悉了，平时在项目中或多或少总能看到Factory, Provider等。确实Factory Method一种创建型的模式，它的主要目的就是隐藏对象创建的细节。也就是说，客户程序（或者成为调用者）不用特定来什么创建某一种具体的类，也不依赖于特定的类，而且依赖接口或者抽象类，这样就达到了解耦，专业点的说法就是“依赖倒置”，更加直白的说法就是：客户程序可以使用很多不同的实现类，而保持代码...

2017-11-09

532

发表评论

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。