实体框架和Eager加载和企业应用程序与DDD aproach [英] Entity framework and Eager loading and enterprise application with DDD aproach

问题描述

ITNOA

我们正在尝试使用实体框架创建一个使用域驱动开发风格模式方法的ASP.NET MVC 4应用程序。我们在域层中可以看到，我们有一个复杂的设计。我们需要加载实体的懒惰和渴望的方法。不幸的是，我们在实体框架中有这些方法的大问题。

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

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

  this.Items =新列表< Item> 
 {
 new Group（
a，
 new List< Item> 
 {
 new Field（b），
 new Field（c） ，
 new Field（d），
  

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

解决方案

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

是的。

真正的域名模型可能与相应的数据模型有所不同，原因很多，企业ORM的目标如EF或NHibernate是在两者之间翻译，甚至到p支持多个数据库的oint。

我真正看不到您的域模型。您的图表看起来像一个数据模型，这是一个实现细节。我希望看到医生，患者，问卷，预约，治疗，处方等。您可以选择以您所描述的风格存储这些（StackOverflow将问题和答案存储为帖子），但这是映射如果您使用的是关系数据库，那么您可能会更喜欢使用类似于域模型的表格。如果要进行完全灵活的存储，RDBMS可能不是正确的工具 - 可能考虑一个文档数据库？

ITNOA

We are trying to create an ASP.NET MVC 4 application using entity framework with domain driven development style pattern approach. As you can see in our part of domain layer, we have a complex design. We need to load entity with lazy as well as eager methods. Unfortunately we have big problem with these methods in entity framework.

As we understand, for eager loading in EF we have to use the Include method and give string of properties and properties of properties etc. (In Hibernate and java we could use annotation top of member to load eagerly and it was so much easier than this approach). But the horrible problem is that we have inheritance structures and heavy polymorphism, in these states we don’t have that’s string we should given to include because we don’t know which derived class of class is selected to understand which properties should include.

For example as you can see a result has a collection of items and then decides to add some group to this collection and each of those groups have some groups and fields (like the composition pattern). Now imagine we want to load a result is like the one talked above. When I want to write a string of given include I don’t know what items of this result are groups. Because we can’t predict these items are groups and so these groups have collection of items which should load.

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

At last we have a critical question: is entity framework designed for Enterprise Applications with a complex domain and DDD approach? If not, how we follow the approach of Martin Fowler and Eric Evans in software engineering and enterprise application in C#?

解决方案

is entity framework designed for Enterprise Applications with a complex domain and DDD approach?

Yes.

A real domain model may differ in shape from the corresponding data model for many reasons. The goal of an "enterprise" ORM like EF or NHibernate is to translate between the two, even to the point of supporting multiple databases.

What I don't really see is your domain model. Your diagram looks like a data model, which is an implementation detail. I'd expect to see Doctor, Patient, Questionnaire, Appointment, Treatment, Prescription etc. You may choose to store these in the style you describe (StackOverflow stores both questions and answers as "Posts", for example) but that's what the mapping is for, and to be honest if you're using a relational database you might be better off having tables that are similar to the domain model. If you're going for a totally flexible storage then an RDBMS is probably not the right tool - consider perhaps a document database instead?

这篇关于实体框架和Eager加载和企业应用程序与DDD aproach的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！