7

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.

Domenic
  • 110,262
  • 41
  • 219
  • 271
  • 2
    You've got at least three questions that boil down to "I don't like ORMs because they compromise my design." ORMs are tools to solve a specific problem. If you don't like them, why use them? Write your own data access layer using ADO.NET. After a few months of typing boilerplate code, you may come to appreciate the trade-offs ORMs introduce. (I did something similar several years ago; I'm not going back.) – TrueWill Mar 19 '11 at 21:15
  • 2
    Yeah, these are all related questions coming up as I start diving into ORMs. But I would rather categorize them as "help me _understand_ the compromises in ORM" questions. I am committed to using an ORM, since as you say data access in ADO.NET is crazy-sauce. It's not that I don't like them, it's that I am still just learning about them and trying to get help putting myself in the right mindset. – Domenic Mar 19 '11 at 21:21
  • 3
    For example, if I was reading EF vs. NHibernate comparisons with questions in mind like "which will induce less compromises in my domain model?", that might be less productive than coming at such comparisons with an idea of what compromises are generally necessary and instead comparing the two frameworks based on features, maturity, capability, etc. – Domenic Mar 19 '11 at 21:23

2 Answers2

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.

BrandonZeider
  • 8,014
  • 2
  • 23
  • 20
0

Having used many ORM's I feel the pain, using interfaces, abstraction, and immutable objects does not work properly with most ORM's. It's for this reason and others that I wrote my own about 8 years ago, I have discovered some of these problems using my own ORM and found ways to address them. I would look at the Micro ORM's and seen what you can find , there are many out there and have a rich features set and many have less baggage.

I have added some new features to mine to handle some of my pains. Like the ability to return collections of interfaces or other abstract types, and immutable types.

    string sql = "Select * from simpleEntities";
    ISqlQuery query = _factory.CreateSqlQuery(sql, nameof(AbstractFactoryTests.ReadImmutableEntityItems));
    IList<IImmutableEntity> items = loader.ObtainItemsImmutable<IImmutableEntity>(query);

or:

    IList<ISqlQuery> queries = new List<ISqlQuery>();

    // Note, no register types needed here because of returnType parameter

    ISqlQuery s1 = _factory.CreateSqlQuery("Select * from Employee where EmployeeType=1", "LoadAbstract.ParallelLoadItems1", typeof(Employee));
    queries.Add(s1);
    ISqlQuery s2 = _factory.CreateSqlQuery("Select * from Employee where EmployeeType=2", "LoadAbstract.ParallelLoadItems2", typeof(Manager));
    queries.Add(s2);
    ISqlQuery s3 = _factory.CreateSqlQuery("Select * from Employee where EmployeeType=3", "LoadAbstract.ParallelLoadItems3", typeof(DistrictManager));
    queries.Add(s3);

     IList<IEmployee> data = loader.ParallelLoadAbstractItems<IEmployee>(_factory, queries);