业务问题与持久性问题有关

Question

我正在使用Entity Framework来处理核心模型和数据库之间的持久性。我无法看到一种令人满意的EF工作方式而不会损害我的域实体只是为了启用持久性。我真的想要实现一个丰富的域模型，它真的不知道它的状态是如何存储的。

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

我宁愿保护我的模型通过保护其相关成员进入无效状态，更喜欢以下内容......

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. 将EntityTypeConfigurations移动到Core程序集中。

3. 让Core和Infrastructure.Data.Ef投射“朋友”并使用内部访问修饰符（我真的很讨厌这个想法）。

4. 接受限制。保留集合进行公开变异，并在它们被持久化之前执行其他一些验证。

5. 忘记EF并返回ADO，NET。

还有其他想法吗？坚持无知是无法实现的目标吗？

谢谢！

Answer 1

我的首选解决方案，在尝试击败EF提交和失败后，是：

1. 创建域实体，完全持久无知。

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

3. 使用来自DB的自动生成，而不是代码优先，除非维护2组实体提供任何好处。通常我发现它不值得。

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

您的ORM（EF）将完全隐藏在您的应用中，只有数据层中的存储库才会与其进行内部交易。

Answer 2

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

• 除了语法相当冗长。