工作情景:之前写接口时候,三步走,加属性,EFcore迁移,更新。然后测接口。这两天有个新需求,也是需要加属性,但是这次不一样,实体的属性是引用了其他实体的属性,迁移完成以后发现迁移记录中Up和Down方法都是空的,意味着表结构没有任何变化。当时第一反应是,数据库的PK和FK,结构不变化是合理的。
然后去看了看ABP官方文档,果然还是DDD的概念没搞清楚。
看了论坛的回复,言简意赅
描述一下实体:
你愿意用10个单独的变量来很散乱的存储
还是愿意用一个带10个隔间的箱子来存储
实体
实体是DDD(Domain Driven Design)中核心概念.Eric Evans是这样描述实体的 "一个没有从其属性,而是通过连续性和身份的线索来定义的对象"
实体通常映射到关系型数据库的表中.
简单理解起来就是,实体就是数据库中的一张表。
实体类
实体都继承自Entity<TKey>
类,如下所示:
public class Book : Entity<Guid>
{
public string Name { get; set; }
public float Price { get; set; }
}
如果你不想继承基类
Entity<TKey>
,也可以直接实现IEntity<TKey>
接口
Entity<TKey>
类只是用给定的主 键类型 定义了一个Id
属性,在上面的示例中是Guid
类型.可以是其他类型如string
, int
, long
或其他你需要的类型.
Guid主键的实体
如果你的实体Id类型为 Guid
,有一些好的实践可以实现:
- 创建一个构造函数,获取ID作为参数传递给基类.
- 如果没有为GUID Id赋值,ABP框架会在保存时设置它,但是在将实体保存到数据库之前最好在实体上有一个有效的Id.
- 如果使用带参数的构造函数创建实体,那么还要创建一个
private
或protected
构造函数. 当数据库提供程序从数据库读取你的实体时(反序列化时)将使用它.
示例实体:
public class Book : Entity<Guid>
{
public string Name { get; set; }
public float Price { get; set; }
protected Book()
{
}
public Book(Guid id)
: base(id)
{
}
}