.NET ORMs, immutable value objects, structs, default constructors, and readonly properties

Question

I am just getting started with .NET ORMs, to the point where I haven't even decided between Entity Framework and NHibernate. But in both cases, I'm running into a problem in that they seem to want me to compromise the integrity of my domain model in various ways, especially on finer points of C# object design. This is one of several questions on the subject.

---

I am very used to enforcing immutability on appropriate properties with a pattern that looks like this:

public class Foo
{
    private readonly string bar;
    public string Bar { return this.bar; }

    public Foo(string bar)
    {
        this.bar = bar;
    }
}

This does not appear to be supported by NHibernate or Entity Framework. They want default constructors and public setters; it appears even private setters (and default constructors) work (sometimes?) because the ORMs can use reflection.

I suppose I can get around these by using private setters and a private default constructor. At least then the public API is not compromised. It is just that I am modifying all of my classes' implementations to add unused private constructors, and having to trust future-Domenic that he understands private on my setters really means "don't call me except in the constructor." The persistence layer is leaking into my domain object design.

It also just seems unnecessary---why can't the ORM know to use the non-default constructor? Maybe they are able to, and I just didn't find the right blog post explaining how.

Finally, in some cases my immutable value objects actually fit well as (immutable) value types, i.e. structs. My guess is that this is possible, since in the database the fields of my struct will show up in the same row that the parent entity is stored. Can you confirm/deny? This blog post looks promising in that it gives an affirmative answer, but the amount of code (which is in fact specific to the value type in question) staggers the mind.

---

It is frustrating that after several years reading books like Effective C# or blogs like those of Eric Lippert, which give great advice on how to design expressive and bulletproof C# objects, the need to use ORMs is making me throw much of that knowledge out of the window. I am hoping that someone here can point out where I am wrong, either in my grasp of their capabilities or in my thinking about domain modeling and the role of ORMs.

Answer 1

As the comments point out, you will have to make some compromises when/if you adopt an ORM. The thing to remember in my opinion is that the gains in productivity far outweigh the "costs" of these compromises.

I did want to point out to you (since you're new to EF) that you can customize the T4 templates that generate EF entities and contexts. I think if you play around with this, you can iron out most of the things you don't like.