CODEWITHSUNDEEP
c#entity-frameworkormdomain-driven-design
NikitaKo
NikitaKo

Reputation: 310

DDD aggregate and entity framework. Which way is preferable?

I am little bit confused about the problem. I have an entity Product that is represented in the database. It looks like POCO. Here is example (I use attributes instead of fluent api for simplicity).

public class Product
{
    [Key]
    public int Id { get; set; }   
    //other properties that have mapping to db
}

But now I want to avoid AnemicDomainModel anti-pattern

So I am going to fill the Product model with methods and properties, that do not have mapping to db, so I should use [Ignore].

public class Product
{
    [Key]
    public int Id { get; set; }   
    [Ignore]
    public object FooProperty { get; set; } 
    //other properties that have mapping to db
    //other properties and methods that do not have mapping to db
}

I think such a way spoils my model. In this article I've found acceptable workaround. Its idea is to separate Product (domain model) and ProductState (state of product that is stored in the database). So Product is wrapper for ProductState.

I really want to know the views of other developers. Thanks a lot for your answers.

I understood that my real question sounds something like that: "Should I separate Data model and domain model? Can I change EF entities from Anemic to Rich?"

Upvotes: 0

Views: 1671

Answers (2)

user978139
user978139

Reputation: 579

The beauty of the Entity Framework is that it allows you to map your database tables to your domain model using mappings which can be defined using the Fluent API, therefore there is no need to have separate data entities. This is in comparison to its predecessor Linq To SQL where you'd map each table to an individual data entity.

Take the following example, for the paradigm of a Student and Course - a student can take many courses, and a course can have many students, therefore a many-to-many relationship in your database design. This would consist of three tables: Student, Course, StudentToCourse.

The EF will allow you to use Fluent API mappings to create the many collections on either side of the relationship without having the intermediate table (StudentToCourse) defined in your model (StudentToCourse has no existence in a DOMAIN MODEL), you would only need two classes in your domain, Student and Course. Whereas in LinqToSQL you'd have to define all three in your model as data entities and then create mappings between your data entities and domain model resulting in lots of plumbing work open to bugs.

The argument of the anaemic vs rich domain model should have little effect on your mapping between your model and database tables, but focuses on where you place the behaviour - in either the domain model or the service layer.

Upvotes: 1

guillaume31
guillaume31

Reputation: 14064

To ensure persistence ignorance of your entities, I've found EF Fluent Mapping to be better than Data Annotations. The mappings are declared in an external file, thus normally your entity doesn't have to change if something in the persistence layer changes. However, there are still some things you can't map with EF.

Vaughn's "backing state object" solution you linked to is nice, but it is an extra layer of indirection which adds a fair amount of complexity to your application. It's a matter of personal taste, but I would use it only in cases when you absolutely need stuff in your entities that cannot be mapped directly because of EF shortcomings. It also plays well with an Event Sourcing approach.

Upvotes: 4

Related Questions