业务关注vs持久性关注

本文关键字：持久性 vs 业务 | 更新日期: 2023-09-27 17:49:15

我使用实体框架来处理我的核心模型和数据库之间的持久性。如果不为了启用持久性而牺牲我的领域实体，我无法找到满意地使用EF的方法。我真的想实现一个丰富的领域模型，它真的不知道它的状态是如何存储的。

例如，EF约定是将多个关系映射到虚拟集合。我意识到我可以使成员受保护，但如果核心模型和entitytypconfigurations在不同的程序集中，这将不起作用。

我宁愿通过保护模型的关联成员来防止模型进入无效状态，我更喜欢下面的方法…

public class MyEntity {
    private ICollection<Thing> myThings { get; set; }
    public ReadOnlyCollection<Thing> MyThings { get { return myThings.AsReadOnly(); } }
    public void AddThing(Thing toAdd) { // validate, etc }
}

我已经确定了可能的解决方案(没有一个我真的很满意)…

  1. 映射到DTO，并让域实体包装它的附属DTO，因此DTO拥有数据，实体拥有行为。

  2. 移动entitytypconfigurations到Core组件

  3. 将Core和Infrastructure.Data.Ef项目设为"好友"，并使用内部访问修饰符(我真的很讨厌这个想法)

  4. 接受限制。

    5. 让集合公开变异，并在持久化它们之前执行一些其他验证。

  5. 忘掉EF，回到ADO,NET。

还有其他的想法吗?坚持无知是一个无法达到的目标吗?

谢谢!

业务关注vs持久性关注

在尝试击败EF并失败后，我的首选解决方案是:

  1. 创建您的域实体，完全忽略持久性

  2. 在您的存储库中，在内部使用EF实体，但是将这些实体映射到您的域实体。您的存储库应该只接受并返回域实体。

  3. 使用数据库自动生成，而不是代码优先，除非维护两组实体提供任何巨大的好处。

当然，正如我所说，这将在膝盖处切断ORM。你不会得到延迟加载，但延迟加载通常在DDD中工作得不好，因为你必须在整个应用程序中一直暴露你的数据库设计。

你的ORM (EF)将完全隐藏在你的应用程序中，只有数据层中的存储库才会与它进行内部处理。

我的建议:远离Fluent Mapping，使用XML。使用.edmx文件，您可以轻松地*映射甚至私有属性。

    除了语法相当冗长。
相关文章：