关联本身不是一个模式,但它在领域建模的过程中非常重要,所以需要在探讨各种模式之前,先讨论一下对象之间的关联该如何设计。我觉得对象的关联的设计可以遵循如下的一些原则:
实体就是领域中需要唯一标识的领域概念。因为我们有时需要区分是哪个实体。有两个实体,如果唯一标识不一样,那么即便实体的其他所有属性都一样,我们也认为他们两个不同的实体;因为实体有生命周期,实体从被创建后可能会被持久化到数据库,然后某个时候又会被取出来。所以,如果我们不为实体定义一种可以唯一区分的标识,那我们就无法区分到底是这个实体还是哪个实体。另外,不应该给实体定义太多的属性或行为,而应该寻找关联,发现其他一些实体或值对象,将属性或行为转移到其他关联的实体或值对象上。比如Customer实体,他有一些地址信息,由于地址信息是一个完整的有业务含义的概念,所以,我们可以定义一个Address对象,然后把Customer的地址相关的信息转移到Address对象上。如果没有Address对象,而把这些地址信息直接放在Customer对象上,并且如果对于一些其他的类似Address的信息也都直接放在Customer上,会导致Customer对象很混乱,结构不清晰,最终导致它难以维护和理解;
在领域中,并不是没一个事物都必须有一个唯一标识,也就是说我们不关心对象是哪个,而只关心对象是什么。就以上面的地址对象Address为例,如果有两个Customer的地址信息是一样的,我们就会认为这两个Customer的地址是同一个。也就是说只要地址信息一样,我们就认为是同一个地址。用程序的方式来表达就是,如果两个对象的所有的属性的值都相同我们会认为它们是同一个对象的话,那么我们就可以把这种对象设计为值对象。因此,值对象没有唯一标识,这是它和实体的最大不同。另外值对象在判断是否是同一个对象时是通过它们的所有属性是否相同,如果相同则认为是同一个值对象;而我们在区分是否是同一个实体时,只看实体的唯一标识是否相同,而不管实体的属性是否相同;值对象另外一个明显的特征是不可变,即所有属性都是只读的。因为属性是只读的,所以可以被安全的共享;当共享值对象时,一般有复制和共享两种做法,具体采用哪种做法还要根据实际情况而定;另外,我们应该给值对象设计的尽量简单,不要让它引用很多其他的对象,因为他只是一个值,就像int a = 3;那么”3”就是一个我们传统意义上所说的值,而值对象其实也可以和这里的”3”一样理解,也是一个值,只不过是用对象来表示。所以,当我们在C#语言中比较两个值对象是否相等时,会重写GetHashCode和Equals这两个方法,目的就是为了比较对象的值;值对象虽然是只读的,但是可以被整个替换掉。就像你把a的值修改为”4”(a = 4;)一样,直接把”3”这个值替换为”4”了。值对象也是一样,当你要修改Customer的Address对象引用时,不是通过Customer.Address.Street这样的方式来实现,因为值对象是只读的,它是一个完整的不可分割的整体。我们可以这样做:Customer.Address = new Address(…);
领域中的一些概念不太适合建模为对象,即归类到实体对象或值对象,因为它们本质上就是一些操作,一些动作,而不是事物。这些操作或动作往往会涉及到多个领域对象,并且需要协调这些领域对象共同完成这个操作或动作。如果强行将这些操作职责分配给任何一个对象,则被分配的对象就是承担一些不该承担的职责,从而会导致对象的职责不明确很混乱。但是基于类的面向对象语言规定任何属性或行为都必须放在对象里面。所以我们需要寻找一种新的模式来表示这种跨多个对象的操作,DDD认为服务是一个很自然的范式用来对应这种跨多个对象的操作,所以就有了领域服务这个模式。和领域对象不同,领域服务是以动词开头来命名的,比如资金转帐服务可以命名为MoneyTransferService。当然,你也可以把服务理解为一个对象,但这和一般意义上的对象有些区别。因为一般的领域对象都是有状态和行为的,而领域服务没有状态只有行为。需要强调的是领域服务是无状态的,它存在的意义就是协调领域对象共完成某个操作,所有的状态还是都保存在相应的领域对象中。我觉得模型(实体)与服务(场景)是对领域的一种划分,模型关注领域的个体行为,场景关注领域的群体行为,模型关注领域的静态结构,场景关注领域的动态功能。这也符合了现实中出现的各种现象,有动有静,有独立有协作。
领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务,那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作,这样一来,领域层可能会把一部分领域知识泄露到应用层。因为应用层需要了解每个领域对象的业务功能,具有哪些信息,以及它可能会与哪些其他领域对象交互,怎么交互等一系列领域知识。因此,引入领域服务可以有效的防治领域层的逻辑泄露到应用层。对于应用层来说,从可理解的角度来讲,通过调用领域服务提供的简单易懂但意义明确的接口肯定也要比直接操纵领域对象容易的多。这里似乎也看到了领域服务具有Façade的功能,呵呵。
说到领域服务,还需要提一下软件中一般有三种服务:应用层服务、领域服务、基础服务。
按照应用层的请求,发送Email通知;
所以,从上面的例子中可以清晰的看出,每种服务的职责;
聚合,它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚,并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合,我们把聚合看作是一个修改数据的单元。
关于如何识别聚合以及聚合根的问题:
我觉得我们可以先从业务的角度深入思考,然后慢慢分析出有哪些对象是:
我觉得这个需要从业务的角度深入分析哪些对象它们的关系是内聚的,即我们会把他们看成是一个整体来考虑的;然后这些对象我们就可以把它们放在一个聚合内。所谓关系是内聚的,是指这些对象之间必须保持一个固定规则,固定规则是指在数据变化时必须保持不变的一致性规则。当我们在修改一个聚合时,我们必须在事务级别确保整个聚合内的所有对象满足这个固定规则。作为一条建议,聚合尽量不要太大,否则即便能够做到在事务级别保持聚合的业务规则完整性,也可能会带来一定的性能问题。有分析报告显示,通常在大部分领域模型中,有70%的聚合通常只有一个实体,即聚合根,该实体内部没有包含其他实体,只包含一些值对象;另外30%的聚合中,基本上也只包含两到三个实体。这意味着大部分的聚合都只是一个实体,该实体同时也是聚合根。
如果一个聚合只有一个实体,那么这个实体就是聚合根;如果有多个实体,那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。
DDD中的工厂也是一种体现封装思想的模式。DDD中引入工厂模式的原因是:有时创建一个领域对象是一件比较复杂的事情,不仅仅是简单的new操作。正如对象封装了内部实现一样(我们无需知道对象的内部实现就可以使用对象的行为),工厂则是用来封装创建一个复杂对象尤其是聚合时所需的知识,工厂的作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数,然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。领域模型中其他元素都不适合做这个事情,所以需要引入这个新的模式,工厂。工厂在创建一个复杂的领域对象时,通常会知道该满足什么业务规则(它知道先怎样实例化一个对象,然后在对这个对象做哪些初始化操作,这些知识就是创建对象的细节),如果传递进来的参数符合创建对象的业务规则,则可以顺利创建相应的对象;但是如果由于参数无效等原因不能创建出期望的对象时,应该抛出一个异常,以确保不会创建出一个错误的对象。当然我们也并不总是需要通过工厂来创建对象,事实上大部分情况下领域对象的创建都不会太复杂,所以我们只需要简单的使用构造函数创建对象就可以了。隐藏创建对象的好处是显而易见的,这样可以不会让领域层的业务逻辑泄露到应用层,同时也减轻了应用层的负担,它只需要简单的调用领域工厂创建出期望的对象即可。
领域建模是一个不断重构,持续完善模型的过程,大家会在讨论中将变化的部分反映到模型中,从而是模型不断细化并朝正确的方向走。领域建模是领域专家、设计人员、开发人员之间沟通交流的过程,是大家工作和思考问题的基础。
从经典的领域驱动设计分层架构中可以看出,领域层的上层是应用层,下层是基础设施层。那么领域层是如何与其它层交互的呢?
一般应用层会先启动一个工作单元,然后:
注意,以上所说的所有领域对象都是只聚合根,另外在应用层需要获取仓储接口以及领域服务接口时,都可以通过IOC容器获取。最后通知工作单元提交事务从而将所有相关的领域对象的状态以事务的方式持久化到数据库;
可以直接通过仓储查询出所需要的数据。但一般领域层中的仓储提供的查询功能也许不能满足界面显示的需要,则可能需要多次调用不同的仓储才能获取所需要显示的数据;其实针对这种查询的情况,我在后面会讲到可以直接通过CQRS的架构来实现。即对于查询,我们可以在应用层不调用领域层的任何东西,而是直接通过某个其他的用另外的技术架构实现的查询引擎来完成查询,比如直接通过构造参数化SQL的方式从数据库一个表或多个表中查询出任何想要显示的数据。这样不仅性能高,也可以减轻领域层的负担。领域模型不太适合为应用层提供各种查询服务,因为往往界面上要显示的数据是很多对象的组合信息,是一种非对象概念的信息,就像报表;
对象将需求用类一个个隔开,就像用储物箱把东西一个个封装起来一样,需求变了,分几种情况,最严重的是大变,那么每个储物箱都要打开改,这种方法就不见得有好处;但是这种情况发生概率比较小,大部分需求变化都是局限在一两个储物箱中,那么我们只要打开这两个储物箱修改就可以,不会影响其他储物柜了。
而面向过程是把所有东西都放在一个大储物箱中,修改某个部分以后,会引起其他部分不稳定,一个BUG修复,引发新的无数BUG,最后程序员陷入焦头烂额,如日本东京电力公司员工处理核危机一样,心力交瘁啊。
所以,我们不能粗粒度看需求变,认为需求变了,就是大范围变,万事万物都有边界,老子说,无欲观其缴,什么事物都要观察其边界,虽然需求可以用“需求”这个名词表达,谈到需求变了,不都意味着最大边界范围的变化,这样看问题容易走极端。
其实就是就地画圈圈——边界。我们小时候写作文分老三段也是同样道理,各自职责明确,划分边界明确,通过过渡句实现承上启下——接口。为什么组织需要分不同部门,同样是边界思维。画圈圈容易,但如何画才难,所以OO中思维非常重要。
需求变化所引起的变化是有边界,若果变化的边界等于整个领域,那么已经是完全不同的项目了。要掌握边界,是需要大量的领域知识的。否则,走进银行连业务职责都分不清的,如何画圈圈呢?
面向过程是无边界一词的(就算有也只是最大的边界),它没有要求各自独立,它可以横跨边界进行调用,这就是容易引起BUG的原因,引起BUG不一定是技术错误,更多的是逻辑错误。分别封装就是画圈圈了,所有边界都以接口实现。不用改或者小改接口,都不会牵一发动全身。若果面向过程中考虑边界,那么也就已经上升到OO思维,即使用的不是对象语言,但对象已经隐含其中。说白了,面向对象与面向过程最大区别就是:分解。边界的分解。从需求到最后实现都贯穿。
面向对象的实质就是边界划分,封装,不但对需求变化能够量化,缩小影响面;因为边界划分也会限制出错的影响范围,所以OO对软件后期BUG等出错也有好处。
软件世界永远都有BUG,BUG是清除不干净的,就像人类世界永远都存在不完美和阴暗面,问题关键是:上帝用空间和时间的边界把人类世界痛苦灾难等不完美局限在一个范围内;而软件世界如果你不采取OO等方法进行边界划分的话,一旦出错,追查起来情况会有多糟呢?
软件世界其实类似人类现实世界,有时出问题了,探究原因一看,原来是两个看上去毫无联系的因素导致的,古人只好经常求神拜佛,我们程序员在自己的软件上线运行时,大概心里也在求神拜佛别出大纰漏,如果我们的软件采取OO封装,我们就会坦然些,肯定会出错,但是我们已经预先划定好边界,所以,不会产生严重后果,甚至也不会出现难以追查的魔鬼BUG。
上面只是涉及到DDD中最基本的内容,DDD中还有很多其他重要的内容在上面没有提到,如:
这些主题都很重要,因为篇幅有限以及我目前掌握的知识也有限,并且为了突出这篇文章的重点,所以不对他们做详细介绍了,大家有兴趣的可以自己阅读一下。
工作单元的目标是维护变化的对象列表。使用IUnitOfWorkRepository负责对象的持久化,使用IUnitOfWork收集变化的对象,并将变化的对象放到各自的增删改列表中,
最后Commit,Commit时需要循环遍历这些列表,并由Repository来持久化。
代码实现如下:
实体接口
namespace Notify.Infrastructure.DomainBase { /// <summary> /// 实体接口 /// </summary> public interface IEntity { /// <summary> /// key /// </summary> object Key { get; } } }
EntityBase,领域类的基类。
namespace Notify.Infrastructure.DomainBase { /// <summary> /// 实体抽象类 /// </summary> public abstract class EntityBase : IEntity { /// <summary> /// 标识key /// </summary> private readonly object key; /// <summary> /// Initializes a new instance of the <see cref="EntityBase"/> class. /// 默认构造函数 default constructor /// </summary> protected EntityBase() : this(null) { } /// <summary> /// Initializes a new instance of the <see cref="EntityBase"/> class. /// </summary> /// <param name="key">key</param> protected EntityBase(object key) { this.key = key; } /// <summary> /// Gets the key. /// </summary> public object Key { get { return this.key; } } /// <summary> /// The equals. /// </summary> /// <param name="other"> /// The other. /// </param> /// <returns> /// The <see cref="bool"/>. /// </returns> protected bool Equals(EntityBase other) { return Equals(this.Key, other.Key); } /// <summary> /// The equals. /// </summary> /// <param name="entity"> /// The entity. /// </param> /// <returns> /// The <see cref="bool"/>. /// </returns> public override bool Equals(object entity) { if (entity == null || !(entity is EntityBase)) { return false; } return this == (EntityBase)entity; } /// <summary> /// The get hash code. /// </summary> /// <returns> /// The <see cref="int"/>. /// </returns> public override int GetHashCode() { return this.Key != null ? this.Key.GetHashCode() : 0; } /// <summary> /// The ==. /// </summary> /// <param name="left"> /// The base 1. /// </param> /// <param name="right"> /// The base 2. /// </param> /// <returns> /// </returns> public static bool operator ==(EntityBase left, EntityBase right) { if ((object)left == null && (object)right == null) { return true; } if ((object)left == null || (object)right == null) { return false; } if (left.Key == null && left.Key == null) { return true; } return left.Key.ToString() == right.Key.ToString(); } /// <summary> /// The !=. /// </summary> /// <param name="left"> /// The base 1. /// </param> /// <param name="right"> /// The base 2. /// </param> /// <returns> /// </returns> public static bool operator !=(EntityBase left, EntityBase right) { return !(left == right); } } /// <summary> /// The entity. /// </summary> /// <typeparam name="T"> /// </typeparam> public abstract class EntityBase<T> : EntityBase { /// <summary> /// Initializes a new instance of the <see cref="EntityBase{T}"/> class. /// Initializes a new instance of the <see cref="EntityBase"/> class. /// 默认构造函数 default constructor /// </summary> protected EntityBase() : base(null) { } /// <summary> /// Initializes a new instance of the <see cref="EntityBase{T}"/> class. /// Initializes a new instance of the <see cref="EntityBase"/> class. /// </summary> /// <param name="key"> /// key /// </param> protected EntityBase(T key) : base(key) { } /// <summary> /// Gets the key. /// </summary> public new T Key { get { T @default = default(T); if (base.Key == null) { return @default; } return (T)base.Key; } } } }
工作单元接口:简单的工作单元接口 只有2个方法一个提交一个回滚
using System; using System.Data; namespace Notify.Infrastructure.UnitOfWork { /// <summary> /// 工作单元接口 /// </summary> public interface IUnitOfWork : IDisposable { /// <summary> /// SQL执行 /// </summary> IDbCommand Command { get; } /// <summary> /// 提交 /// </summary> void Complete(); /// <summary> /// 回滚 /// </summary> void Rollback(); } }
简单的工作单元实现
using System.Data; using Notify.Infrastructure.UnitOfWork; namespace Notify.DbCommon.UnitOfWork { /// <summary> /// 工作单元 /// </summary> public class UnitOfWork : IUnitOfWork { /// <summary> /// Initializes a new instance of the <see cref="UnitOfWork"/> class. /// 设置事务隔离级别 /// </summary> /// <param name="name"> The connection String.</param> public UnitOfWork(string name) { this.Conn = DbFactories.GetConnection(name); this.Command = this.Conn.CreateCommand(); this.Transaction = this.Conn.BeginTransaction(); this.Command.Transaction = this.Transaction; } /// <summary> /// 链接 /// </summary> protected IDbConnection Conn { get; set; } /// <summary> /// 事务 /// </summary> protected IDbTransaction Transaction { get; set; } /// <summary> /// SQL执行 /// </summary> /// <summary> /// IDbCommand /// </summary> public IDbCommand Command { get; private set; } /// <summary> /// 提交事务 /// </summary> public virtual void Complete() { this.Transaction.Commit(); } /// <summary> /// 回滚事务 /// </summary> public virtual void Rollback() { this.Transaction.Rollback(); } /// <summary> /// 释放资源 /// </summary> public virtual void Dispose() { if (this.Transaction != null) { this.Transaction.Dispose(); this.Transaction = null; } if (this.Command != null) { this.Command.Dispose(); this.Command = null; } if (this.Conn != null) { this.Conn.Dispose(); this.Conn.Close(); this.Conn = null; } } } }
复杂一点的工作单元实现
就是需要手动将要执行的方法注册到工作单元 这时候就需要一个 注册工作单元接口
using System; using Notify.Infrastructure.DomainBase; using Notify.Infrastructure.RepositoryFramework; namespace Notify.Infrastructure.UnitOfWork { /// <summary> /// InvokeMethod /// </summary> /// <param name="entity"> /// The entity. /// </param> public delegate void InvokeMethod(IEntity entity); /// <summary> /// 注册工作单元接口 /// </summary> public interface IPowerUnitOfWork : IUnitOfWork { /// <summary> /// 注册新增实体工作单元仓储接口 /// </summary> /// <param name="entity">待新增实体接口</param> /// <param name="repository">工作单元仓储接口</param> void RegisterAdded(IEntity entity, IUnitOfWorkRepository repository); /// <summary> /// 注册修改实体工作单元仓储接口 /// </summary> /// <param name="entity">待修改实体接口</param> /// <param name="repository">工作单元仓储接口</param> void RegisterChanged(IEntity entity, IUnitOfWorkRepository repository); /// <summary> /// 注册删除实体工作单元仓储接口 /// </summary> /// <param name="entity">待删除实体接口</param> /// <param name="repository">工作单元仓储接口</param> void RegisterRemoved(IEntity entity, IUnitOfWorkRepository repository); /// <summary> /// 注册一个其他非基础的增删改工作单元仓储接口 /// </summary> /// <param name="entity">待操作实体接口</param> /// <param name="methodName">自定义委托</param> void RegisterInvokeMethod(IEntity entity, InvokeMethod methodName); /// <summary> /// 注册一个非继承聚合根的其他非基础的增删改工作单元仓储接口 /// </summary> /// <param name="entity">待操作实体接口</param> /// <param name="methodName">Action委托</param> void RegisterAction(object entity, Action<object> methodName); /// <summary> /// 注册一个非继承聚合根的其他非基础的增删改工作单元仓储接口 /// </summary> /// <param name="entity">待操作实体接口</param> /// <param name="methodName">Func委托</param> void RegisterFunc(object entity, Func<object, object> methodName); } }
复杂的工作单元则需要 实现注册工作单元接口 并且继承简单工作单元基类 扩展实现(开放封闭原则)
using System; using System.Collections.Generic; using Notify.Code.Write; using Notify.Infrastructure.DomainBase; using Notify.Infrastructure.RepositoryFramework; using Notify.Infrastructure.UnitOfWork; namespace Notify.DbCommon.UnitOfWork { /// <summary> /// 工作单元 /// </summary> public class PowerUnitOfWork : UnitOfWork, IPowerUnitOfWork { /// <summary> /// 新增实体工作单元 /// </summary> private readonly Dictionary<IEntity, IUnitOfWorkRepository> m_addedEntities; /// <summary> /// 修改实体工作单元 /// </summary> private readonly Dictionary<IEntity, IUnitOfWorkRepository> m_changedEntities; /// <summary> /// 删除实体工作单元 /// </summary> private readonly Dictionary<IEntity, IUnitOfWorkRepository> m_deletedEntities; /// <summary> /// 其他非基础的增删改 /// </summary> private readonly Dictionary<IEntity, InvokeMethod> m_invokeEntities; /// <summary> /// 非继承聚合根的其他非基础的增删改工作单元 /// </summary> private readonly Dictionary<object, Action<object>> m_action; /// <summary> /// 非继承聚合根的其他非基础的增删改工作单元 /// </summary> private readonly Dictionary<object, Func<object, object>> m_func; /// <summary> /// Initializes a new instance of the <see cref="PowerUnitOfWork"/> class. /// </summary> /// <param name="connectionSetting"> /// The connection setting. /// </param> public PowerUnitOfWork(string connectionSetting) : base(connectionSetting) { this.m_addedEntities = new Dictionary<IEntity, IUnitOfWorkRepository>(); this.m_changedEntities = new Dictionary<IEntity, IUnitOfWorkRepository>(); this.m_deletedEntities = new Dictionary<IEntity, IUnitOfWorkRepository>(); this.m_invokeEntities = new Dictionary<IEntity, InvokeMethod>(); this.m_action = new Dictionary<object, Action<object>>(); this.m_func = new Dictionary<object, Func<object, object>>(); } /// <summary> /// 提交工作单元 /// </summary> public override void Complete() { try { foreach (IEntity entity in this.m_deletedEntities.Keys) { this.m_deletedEntities[entity].PersistDeletedItem(entity); } foreach (IEntity entity in this.m_addedEntities.Keys) { this.m_addedEntities[entity].PersistNewItem(entity); } foreach (IEntity entity in this.m_changedEntities.Keys) { this.m_changedEntities[entity].PersistUpdatedItem(entity); } foreach (IEntity entity in this.m_invokeEntities.Keys) { this.m_invokeEntities[entity](entity); } foreach (var entity in this.m_action) { entity.Value(entity.Key); } foreach (var entity in this.m_func) { entity.Value(entity.Key); } base.Complete(); } catch (Exception exception) { this.Rollback(); LogService.WriteLog(exception, "工作单元提交失败"); throw; } finally { this.Dispose(); this.Clear(); } } /// <summary> /// 注册新增实体工作单元仓储接口 /// </summary> /// <param name="entity">待新增实体接口</param> /// <param name="repository">工作单元仓储接口</param> public void RegisterAdded(IEntity entity, IUnitOfWorkRepository repository) { this.m_addedEntities.Add(entity, repository); } /// <summary> /// 注册修改实体工作单元仓储接口 /// </summary> /// <param name="entity">待修改实体接口</param> /// <param name="repository">工作单元仓储接口</param> public void RegisterChanged(IEntity entity, IUnitOfWorkRepository repository) { this.m_changedEntities.Add(entity, repository); } /// <summary> /// 注册删除实体工作单元仓储接口 /// </summary> /// <param name="entity">待删除实体接口</param> /// <param name="repository">工作单元仓储接口</param> public void RegisterRemoved(IEntity entity, IUnitOfWorkRepository repository) { this.m_deletedEntities.Add(entity, repository); } /// <summary> /// 注册一个其他非基础的增删改工作单元仓储接口 /// </summary> /// <param name="entity">待操作实体接口</param> /// <param name="methodName">自定义委托</param> public void RegisterInvokeMethod(IEntity entity, InvokeMethod methodName) { this.m_invokeEntities.Add(entity, methodName); } /// <summary> /// 注册一个非继承聚合根的其他非基础的增删改工作单元仓储接口 /// </summary> /// <param name="entity">待操作实体接口</param> /// <param name="methodName">Action委托</param> public void RegisterAction(object entity, Action<object> methodName) { this.m_action.Add(entity, methodName); } /// <summary> /// 注册一个非继承聚合根的其他非基础的增删改工作单元仓储接口 /// </summary> /// <param name="entity">待操作实体接口</param> /// <param name="methodName">Func委托</param> public void RegisterFunc(object entity, Func<object, object> methodName) { this.m_func.Add(entity, methodName); } /// <summary> /// 清除 /// </summary> private void Clear() { this.m_addedEntities.Clear(); this.m_changedEntities.Clear(); this.m_deletedEntities.Clear(); this.m_invokeEntities.Clear(); this.m_action.Clear(); this.m_func.Clear(); } } }
上篇--仓储基础接口
下篇--仓储实现