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#?
5
is entity framework designed for Enterprise Applications with a complex domain and DDD approach?
This might be only me, but I have yet to find an ORM that would allow you to create a clean DDD model and have it seamlessly mapped to relational data model. You always need some level of change to your DDD to support the ORM mapping. The lazy loading is one of them. Requirement for public properties or parameter-less constructors is another I noticed.
If not, how we follow the approach of Martin Fowler and Eric Evans in software engineering and enterprise application in C#?
I think that original idea of DDD was that there was persistence layer on top of DDD that was specifically tailored for that specific model. Quite often going as low as pure SQL. ORMs being generic frameworks don’t have luxury of that specific way of mapping. Some, like nHibernate, get close simply because of their scale and amount of features. But I still think ORM mappers can’t generally be used to map properly designed DDD to relational without changes to the DDD model.
2