ABP官方文档翻译 3.1 实体

实体

  实体是DDD(领域驱动设计)的核心概念之一。Eric Evans描述它为"An object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity."所以,实体有Id并存储在数据库。实体一般映射到关系库中的表。

实体类

  在ABP,实体继承自Entity类。如下示例:

复制代码
public class Person : Entity
{
    public virtual string Name { get; set; }

    public virtual DateTime CreationTime { get; set; }

    public Person()
    {
        CreationTime = DateTime.Now;
    }
}
复制代码

  Persion类定义为实体。它有两个属性,实体类还定义了Id属性,它是实体的主键。所以,所有实体主键的名字都一样,为Id。

  Id(主键)的类型可以改变,默认为int(Int32)类型。如果想定义其他类型作为Id,可以按如下所示显示的声明:

复制代码
public class Person : Entity<long>
{
    public virtual string Name { get; set; }

    public virtual DateTime CreationTime { get; set; }

    public Person()
    {
        CreationTime = DateTime.Now;
    }
}
复制代码

  还可以将主键类型设置为String、Guid或其他类型。

  实体类重写了相等运算符(==),可以方便的检查两个实体是否相等(Id相同)。实体还定义了IsTransient()方法检查是否有Id。

聚合根类

  “在DDD中,聚合是一种模式。一个DDD聚合是领域对象群集,这些领域对象可以作为一个单元对待。例如订单和它的行项目,这些是独立的对象,但是把订单(和它的行项目)作为一个聚合对待是有用的。”(Martin Fowler -参见详细描述)。

  虽然ABP不强制使用聚合,在应用中,我们或许想创建聚合和聚合根。ABP定义了AggregateRoot类,它扩展了实体为聚合创建聚合根实体。

领域事件

  聚合根定义了领域事件集合,通过聚合根类产生领域事件。这些事件在当前工作单元完成之前自动触发。实际上,任何实体可以通过实现IGeneratesDomainEvents接口来生成领域事件,但是,通常在(最佳实践)聚合根中生成领域事件。这就是为什么默认为聚合根而不是其他实体类。

常规接口

  在许多应用中,相似的实体属性(和数据库表字段)被使用,如CreationTime表示实体什么事件被创建。ABP提供了一些有用的接口使这些常见属性显示声明。这也提供了编写实体常用代码的一种方式,实现这些接口。

审计

  IHasCreationTime使实体拥有一个常用的"creation time"属性。当实现了这个接口的实体被插入到数据库时,ABP自动设置CreationTime为当前时间。

public interface IHasCreationTime
{
    DateTime CreationTime { get; set; }
}

  ABP自动设置CreatorUserId为当前用户Id,当保存一个新实体的时候。也可以通过将实体继承CreationAuditedEntity类来实现ICreationAudited接口。它也有一个泛型版本,可以实现不同类型的Id属性。

  修改也有类似的接口:

复制代码
public interface IHasModificationTime
{
    DateTime? LastModificationTime { get; set; }
}

public interface IModificationAudited : IHasModificationTime
{
    long? LastModifierUserId { get; set; }
}
复制代码

  当更新实体时,ABP自动设置这些属性。只需要在实体中定义他们。

  如果想实现所有的审计属性,可以直接实现IAudited接口:

public interface IAudited : ICreationAudited, IModificationAudited
{

}

  有一个捷径,可以直接继承AuditedEntity类而不是直接实现IAudited接口。AuditedEntity类也有一个泛型版本,以适应不同类型的Id属性。

  注意:ABP从ABP会话中获取当前用户Id。

软删除

  软删除是常用的模式,用来标记实体删除而不是真的从数据库中删除。例如,可能不想从数据库中硬删除一个用户,因为它和其他表有许多关系。ISoftDelete接口用来实现这个目的:

public interface ISoftDelete
{
    bool IsDeleted { get; set; }
}

  ABP实现了开箱即用的软删除模式。当软删除实体被删除时,ABP会检测到并阻止删除,设置IsDeleted为true,然后更新实体到数据库。ABP不会从数据库中获取(select)软删除的实体,自动过滤他们。

  如果使用软删除,也想记录实体什么时候被删除、谁删除,可以实现IDeletionAudited接口,如下所示:

复制代码
public interface IDeletionAudited : ISoftDelete
{
    long? DeleterUserId { get; set; }

    DateTime? DeletionTime { get; set; }
}
复制代码

  IDeletionAudited扩展了ISoftDelete接口。当实体被删除时,ABP自动记录这些属性。

  如果想让实体实现所有的审计接口(creation、modification和deletion),可以直接实现IFullAudited接口,因为它继承自所有接口:

public interface IFullAudited : IAudited, IDeletionAudited
{

}

  有个捷径,可以使实体继承自FullAuditedEntity类,它实现了所有。

  • NOTE1:所有的审计接口和类都有一个泛型版本,用来定义User实体(如ICreationAudited<TUser>和FullAuditedEntity<TPrimaryKey,TUser>)的导航属性。
  • NOTE2:所有这些都有一个聚合根版本,如AuditedAggregateRoot。

激活/失活实体

  一些实体需要被记录为激活或失活。然后可以基于实体的激活/失活状态进行操作。可以实现IPassiveable接口,这个接口便是为这个目的设计的。它定义了IsActive属性。

  如果实体第一次创建时为激活状态,那么可以在构造函数中设置IsActive为true。

  这和软删除(IsDeleted)是不同的。如果实体被软删除,它不能从数据库中获取(ABP默认会阻止获取),但是,对于激活/失活的实体,控制获取实体完全由自己决定。

实体改变事件

  当实体被插入、更新或删除时,ABP自动触发这些确定的事件。然后,我们可以注册这些事件,执行需要的任何逻辑。参见在事件总线文档的预定义事件部分了解更多信息。

IEntity接口

  实际上,Entity类实现了IEntity接口(Entity<TPrimaryKey>实现了IEntity<TPrimaryKey>)。如果不想从Entity类集成,可以直接实现这些接口。其他实体类也有相关的接口。但是,不建议使用这种方式,除非有好的理由不从Entity类继承。

 

返回主目录

posted @ 2017-05-18 21:29  罗志均  阅读(394)  评论(0编辑  收藏  举报
友情链接:回力 | 中老年女装 | 武汉英语培训机构 | 留学费用一览表 | 托福考试费用