使用TDD方法的实体框架和Eager加载和企业应用程序

Question

ITNOA

我们正在尝试使用具有域驱动开发样式模式方法的实体框架来创建ASP.NET MVC 4应用程序。正如您在我们的域层中所看到的，我们有一个复杂的设计。我们需要使用lazy和eager方法加载实体。不幸的是，我们在实体框架中对这些方法存在很大问题。

正如我们所理解的，对于EF中的急切加载，我们必须使用Include方法并给出属性的属性和属性等。（在Hibernate和java中，我们可以使用成员的注释顶部来加载，并且它比这种方法容易得多）。但是可怕的问题是我们有继承结构和重多态，在这些状态中我们没有我们应该包含的字符串，因为我们不知道选择了哪个派生类来理解应该包含哪些属性。 / p>

例如，您可以看到结果包含一组项目，然后决定将一些组添加到此集合中，并且每个组都有一些组和字段（如组合模式）。现在想象一下我们想要加载一个结果就像上面谈到的那样。当我想写一个给定包含的字符串时，我不知道这个结果的哪些项是组。因为我们无法预测这些项目是组，因此这些组具有应加载的项目集合。

this.Items = new List<Item> 
            {
                new Group(
                    a,
                    new List<Item>
                    { 
                        new Field(b),
                        new Field(c),
                        new Field(d),

最后，我们有一个关键问题：是否为具有复杂域和DDD方法的企业应用程序设计的实体框架？如果没有，我们如何遵循Martin Fowler和Eric Evans在C＃中的软件工程和企业应用方法？

Answer 1

  

是为具有复杂域和DDD方法的企业应用程序设计的实体框架吗？

是

出于多种原因，真实域模型的形状可能与相应的数据模型不同。像EF或NHibernate这样的“企业”ORM的目标是在两者之间进行转换，甚至是支持多个数据库。

我真正看不到的是你的域名模型。您的图表看起来像一个数据模型，这是一个实现细节。我希望看到医生，患者，问卷调查，预约，治疗，处方等。您可以选择以您描述的方式存储这些（例如，StackOverflow将问题和答案存储为“帖子”），但这就是映射是的，并且说实话，如果你使用关系数据库，你可能最好有一个类似于域模型的表。如果你想要一个完全灵活的存储，那么RDBMS可能不是正确的工具 - 或许考虑一个文档数据库呢？