Signs You Need A Hobby, Part 26: Data Access Stimulates You

Here's a manifesto about Microsoft's Entity Framework. I need you to understand something about the tone of this message: there's actually enough people who feel passionately about data access to write a manifesto about Microsoft's Entity Framework, and I frankly find that shocking. You know what? If you care about this so much, go look at a mountain, have sexual intercourse, do some old-school breakdancing, do some tequila shots. Seriously, time to prioritize.

I gotta pick this blog post apart. I realize that, in doing so, I am lowering myself to that level, but if it's any colsolation it's already 3:00 in the afternoon so I'm probably already drunk while I write this.

Let's start with a few choice quotes:

The signatories of this letter are unanimous in expressing concern for the
welfare of software projects undertaken in the Microsoft customer community that
will make use of the forthcoming ADO .NET Entity Framework.

And here's another:

We remain willing to collaborate with Microsoft and the ADO .NET Entity
Framework team to forge a positive action plan to help the Microsoft customer
community achieve success with entity architecture applications.

Now if the first quote was written like this:

The signatories of this treaty are unanimous in expressing concern for the
welfare of Palestinians living in the West Bank community that
will need to make use of the forthcoming UN emergency aid package.

And the second like this:

We remain willing to collaborate with the UN Security Council and the Israeli government and millitary to forge a positive action plan to help the Palestinian Authority achieve success with its efforts to support innocent civilians.

I could understand the need for enthusiasm. But let me reiterate: THIS IS A FUCKING DATA ACCESS LAYER. I don't normally like to swear, particularly in all caps, but seriously.

There's also a ton of technical statements that are basically phrased like "most people think you can access data in more than one way, but we members of the Entity Zealot community believe there can be only one, and only morons don't recognize that ours is the one true path." For example:

The Entity Framework encourages the Anemic Domain Model anti-pattern by
discouraging the inclusion of business logic in the entity classes.

I'm sorry, "Anemic Domain Model"? Ever heard of messaging oriented applications? Also, how do you propose taking your non-anemic domain model and spreading it over a WSDL boundary? Is there no value in a data-only approach? Normally one might suggest that the article in question merely suggests one possible way of doing things; however, by referring to "data-only objects" as the "Anemic Domain Model anti-pattern", I think it's basically saying only fuck-ups use it.

I'll restrict myself to two more rebuttals, even though I could really get stoopid and just comment on every sentence in this document.

Here's something on lazy loading:

Lazy loading is an essential capability of a data access framework for
entity-based applications. Without lazy loading, an entity-based application’s
codebase will need to include unnecessary prescriptive data loading procedures
for every possible business scenario in which the business entities will be
used.

I'd probably add the following sentence to this quote: "Of course, you will have to augment the built-in lazy loading capabilities of most ORMs with a large amount of optimization hints and restrictions on use to avoid making 47 round-trips to the database every time you ask for a simple set of information, but hey, that's definitely easier than writing a SQL statement. I mean, 'Select Name from People', what the hell does that mean?"

Last one: Here's something on the value of "persistence ignorance":

A team’s ability to do evolutionary design and incremental delivery is
damaged by the Entity Framework’s inattention to fundamental software design
principles like Separation of Concerns.

I always enjoy it when a person writes "Separation of Concerns" but they really mean "Separation of Concerns exactly as I would implement it". Has it occurred to no one that lazy loading, by hiding the fact that property accesses may or may not return to a database depending on current cache state, forces a business application to be heavily dependent on side effects or non-functional behaviors that are generally difficult to understand fully enough to predict with any certainty the final behavior of the system? Isn't it of benefit to be explicit when you say, "Now I'd like you to go to a database, which is historically the bottleneck in an enterprise application, and perform your multi-millisecond activity?"

This is exactly why I stopped working on my custom LINQ provider stuff. I've come to realize that the data access question is simply a problem we've already solved a thousand times, and each solution has its own advantages and disadvantages; the intelligentsia is better served by focusing on technology choices that actually have a direct impact to clients.

One last dig: whether you like it or not, if you are a big ORM advocate you should probably just go back to .NET 1.1 and stick with typed datasets. I've heard all the arguments about what makes ORMs great, and I could argue that typed datasets do each of those features better. (FYI: I HATE typed datasets.)