Entity Framework: storing as a list of complex type

Question

I am kinda new with entity framework, I have the following scenario which I want to persist on DB with entity framework:

public class Period
{
    public Period() { }
    public DateTime From { get; set; }
    public DateTime To { get; set; }        
}

public class Class1
{
     public Period Validity {get; set;}
}

public class Class2
{
     public List<Period> Validities {get;set;}
}

I can persist Class1 configuring Period as a complex type, but then I cannot persist Class2.
I can persist Class2 configuring Period as an Entity, but then Class1 doesn't work when trying to add Class1.

And also, Period is not an entity, I don't want to treat it as an entity, I don't want to place an ID on Period, because my model has no sense with it. It was a struct and I has to make it become a class, already.

I would like to keep my existing model as it is now. Is it there a workaround or something that can allow me to define mapping at a lower level?

Would it be possible with NHibernate 4? I am ready to switch my all persistence layer to nhibernate, if worth it! Any hints?

Answer 1

If you try to squeeze your (non-anemic) domain model into an ORM, you will always have to make compromises. So this is usually not a good idea except for very simple applications.

Create a persistence model that consists of dead-simple, getter-setter-only classes without any logic. Make them in a way that fits EF well and use them to persist data. Now map your persistence model to your domain model an vice-versa.

This may seem like overkill, but is the only clean solution if you really want to apply DDD. Try to keep the two models close, so that the mapping is simple. Automapper is a good tool for this kind of model-to-model mapping.

Answer 2

You can't do exactly what you ask in NHibernate, but we know ORMs are all about tradeoffs. What do you really gain from Period having no ID ? Are you ever going to try to equate a Period from Class1 with a Period from Class2 using value equality ?

I usually care a lot more about the semantic benefit of VO's than their shape (no ID, comparison by value, etc.) In other words, I think making domain concepts explicit by grouping anonymous primitive values into well-named VO's is more important than not mistaking Entities for Value Objects or the other way around.

Thus I'm willing to sacrifice a bit of "purity" to still get the benefits of an ORM and not have to create an extra "data model" layer and the extra mapping that goes with it.

This doesn't mean you shouldn't try to find sense in Period being an Entity. Depending on your context, it may be possible. This article shows a solution where the VO is treated as a NHibernate Component when seen from its host object but as an Entity when created/edited. It might be a good middle ground option.