【问题标题】:DDD Mapping Entity Framework Data Model to Domain modelsDDD 将实体框架数据模型映射到域模型
【发布时间】:2016-10-25 08:34:47
【问题描述】:

我知道实体数据模型应该与真正的领域模型分开,以避免基础设施问题和领域本身之间的耦合,但我想知道如果所有领域属性都没有公共设置器,我们如何从数据模型映射到领域模型,特别是如果存储库实现驻留在项目的基础设施部分,所以我们不能使用内部属性设置器。

class DomainModel
{
    string SomeProperty {get; private set:}
}

【问题讨论】:

  • 用构造函数传递参数。但是 EF 已经是存储库模式和工作单元,为什么还需要基于它的另一个抽象?另外,如果您先使用代码,则不需要数据模型;只需将数据库映射到域模型。
  • @L-Four 如果 2 个不同的域模型共享同一个基础结构表,或者您需要复杂属性中的复杂属性怎么办?
  • 然后使用“实体拆分”等技术。不确定您对复杂属性中的复杂属性的含义。
  • @L-Four Employee 可以有位置,可以是地址名称、街道号码、邮政编码和geo_information 的复杂类型,geo_information 可以是另一种复杂类型,这意味着你需要有嵌套的复杂类型特性。我认为实体框架不支持这一点,这意味着您的域模型将受到基础设施问题的限制。
  • 当然支持,通过导航属性。

标签: c# entity-framework entity-framework-6 domain-driven-design


【解决方案1】:

在您拥有中间“数据模型”的架构中,实体框架不再控制您的域实体的实例化方式。您的存储库有。所以它们不一定需要公共 setter,你也可以使用构造函数重新水化它们。

这里解释了一种这样的技术:https://vaughnvernon.co/?p=879

请注意,如果您认为 EF 对您的实体产生的小影响是合理的权衡,那么更简单的替代方法可以是避免使用额外的数据模型并使用私有设置器(请参阅https://lostechies.com/jimmybogard/2014/04/29/domain-modeling-with-entity-framework-scorecard/)。

【讨论】:

    【解决方案2】:

    我了解实体数据模型应该与真实领域模型分开

    不正确

    避免基础设施关注点和域本身之间的耦合

    是的


    可以使用 EF 直接持久化您的领域模型,但是您不应该将您的领域模型耦合到 EF。

    这看起来像什么?

    假设您有一个名为 Domain 的项目,其中包含您的模型,另一个名为 DataStore 的项目包含您的存储库以保存所述模型(使用 EF)

    现在通常使用 EF,您会在要保留的模型上使用属性和各种废话,但这会污染并将这些模型耦合到 EF 作为存储机制,并从您的纯 Domain 项目中添加对 EF 的依赖项 -这是我们试图避免的。

    EF6 进行救援,看看EF6 FluentApi,您可以配置您的域模型以使用 EF,而无需向Domain 项目添加任何 EF 特定属性或依赖项。

    主键?

    modelBuilder.Entity<OfficeAssignment>().HasKey(t => t.InstructorID);
    

    索引?

    modelBuilder 
    .Entity<Department>() 
    .Property(t => t.Name) 
    .HasColumnAnnotation("Index", new IndexAnnotation(new IndexAttribute()));
    

    现在,如果您对每个对象都执行此操作,这将很快变得很痛苦,但是如果您坚持一些约定(或使用基类型使这更容易)

    然后您可以使用反射为您域中的所有实体执行此auto-magically

    祝你好运

    【讨论】:

    • 我有点晚了,但是当你不希望导航属性污染你的域模型时,你如何解决 fluent api 中的外键?
    猜你喜欢
    • 2020-06-26
    • 1970-01-01
    • 1970-01-01
    • 2011-08-28
    • 1970-01-01
    • 2015-11-12
    • 2016-08-31
    • 1970-01-01
    • 2015-10-26
    相关资源
    最近更新 更多