Don’t like EF 4.1 ‘Data Annotations’ for DDD Architectures implementation –’Fluent API’ fits better for that!


I write this post in order to get some feedback regarding what I currently think about EF 4.1 Data Annotations and how it fits in DDD Architectural styles.

About DDD Architectural styles, here it is our Architecture Guide (Though we are actually writing its second edition, adding EF 4.1 Code-First approach). But most DDD Architectural concepts and patterns are exposed there:

http://msdn.microsoft.com/es-es/architecture/en/

The subject I want to toss about is the following:

In DDD architecture designs we must isolate our Domain Model Layer and therefore, our Domain Entities from any other layer, especially from infrastructure layers, like Data Persistence layers where we have the selected data technology (like EF or NHibernate, etc.). Even more, our Domain Classes (Entities, Value-Objects, Domain Services, etc.) should comply the PERSISTENCE IGNORANCE PRINCIPLE. This is why POCO Entities are the right choice for DDD.

Ok, then here we come with EF 4.1 CODE-FIRST approach, which is great for POCO Domain entities and fits great within DDD Architectural styles. Cool!

If you deep-dive a bit into EF 4.1 CODE-FIRST, you’ll see that the initial way to make the mappings from your POCO Domain Entities classes towards your final database tables is based on conventions. Ok, that is nice, but then, if those conventions are not ok for you (because you need to adjust to an existing database or whatever), then you need to customize those conventions. You can do that either in two ways:

Data Annotations. For any of you that might not know what is EF 4.1 ‘Data Annotations’, here you have a link:

http://msdn.microsoft.com/en-us/data/gg193958 

Fluent API. Regarding EF 4.1 ‘Data Annotations’, here you have another link:

http://msdn.microsoft.com/en-us/data/gg194005

What I think is the following:

‘Data Annotations’ might initially look very appealing and easy to use when decorating our classes with attributes, but, on the other hand, and from a POCO point of view, it is a bit intrusive on our Domain entities, as we need to write specific attributes which are links to a specific persistence infrastructure, like EF 4.1. Even when most EF ‘Data Annotation’ attributes are defined within the ‘System.ComponentModel.DataAnnotations’ namespace which is part of the .NET Framework, still it is a bit intrusive on our Domain Entities.

On the other hand, using ‘Default Conventions’ or customizing it with ‘Fluent API’ is a way that fits much better with the PI (Persistence Ignorant), because our Domain Model will be ignorant of those mappings which will be defined into our Data Persistence Infrastructure layer, so, our Domain Model Layer will be better isolated from infrastructure implementation.

Therefore, if you are starting your project from scratch, the best way to go would probably be this: “Base your entity classes on default conventions, as much as you can”, because then your POCO domain entities will be cleaner, pure POCO!. Additionally, using ‘Fluent API’ would be transparent towards your Domain Entity Classes and you won’t stain your POCO Domain Entities, either.

We should make use of the Code First ‘Fluent API’ in order to change/customize our entity mappings, however, it must be written overriding DbContext methods (within our EF Context class). Specifically, we must override the ‘DbContext OnModelCreating()’ method. Therefore, that is part of the Data Persistence Infrastructure Layer, so we won’t be messing on our POCO Domain Entities.

Thoughts?, Comments? Smile

Comments (6)

  1. Daren says:

    I agree wholeheartedly, it muddies the domain.

    An alternative view however is that since EF supports many other database types, ie MySQL, Oracle, DB2 etc, the annotations can still be used against other Database types, so even if you change our your back-end you will still have a lot of flexibility and not even have to touch those annotations.

  2. Diego says:

    What about the use of MetadataType to annotate the model classes? In this way you still keep the benefits of client validation without cluttering the model classes (still you have to put one attribute in the model class).

  3. @ M.Aghaei

    In DDD, Domain Entities should only be part of your Domain-Model.

    Client validation is part of Presentation Layer. In there you should use a data model which should be decoupled from the Domain Model, like DTOs, etc. Then, on those DTOs you could use any client validation you want to use.

  4. I'm new user of EF framework. In ASP.NET MVC data annotations give us automatic client validation (unobtrusive Javascript validation). Using fluent API, we lose such useful feature. What happens to automatic UI validation? I mean how do we can keep POCO entity clean and have client validation at same type in a true way?

  5. John says:

    I agree. The data annotations muddle the architecture. The second you add them, separation of  concerns flies out the window in my opinion. It gets even worse when you combine them with annotations for MVC. Now you have presentation logic muddled in as well.

    It is a little better now that they have moved Data Annotations into the core framework.

  6. Tonko says:

    Agreed, there are other reasons why I dislike intrusive annotations, but this is certainly one of them

Skip to main content