There has been something nagging me tremendously about the Entity Framework Vote of No Confidence. I haven’t had the time up to now to put my thoughts together regarding this. Now that I’ve got a little more breathing room, I think it’s time that I address the elephant in the living room.
Here is what Roger Jennings argue are the major pain points as reported by Mary-Jo Foley:
1. Domain-driven design (objects-first) is today’s hot design pattern for enterprise apps and requires starting with optimal design of business objects and relationships, not from the schema of a relational database whose only job is to persist (store) the objects. Microsoft has always had a data-centric (data-first), forms-over-data approach to pseudo business objects. Data-first can lead to suboptimal business object design.
2. Persistence ignorance requires Plain Old CLR Object (POCO) because it enables separation of concerns, which is de rigeur in today’s layered/tiered software designs. (Persistence ignorance won’t be part of the Entity Framework until Version 2, Jennings noted.)
3. Test-driven design (TDD). MSFT came late to the TDD and Agile Programming table and is trying to catch up. However, no one on the Entity Framework team worried about testability during the design phase. The problem is that performance of unit tests with business objects connected to databases is terrible.
Let’s talk about these in order:
- Looking past obvious argument that “today’s hot design pattern” is tomorrow’s “what were they thinking” (anyone still trying to use CORBA as core of their distributed architecture), Microsoft’s strategy has always been to make getting a “working” solution as painless as possible. Besides calling DDD “today’s hot design pattern” is akin to calling the computer “today’s hot information storage medium.” It severely demeans the timelessness of the core concepts of DDD.
I know that for some (me included), considerations like maintainability, flexibility, and scalability are a concern when designing and developing applications. However, for better or worse, there are some people who just want functional software (the scary reality is that the latter group outnumbers the former by a LOT). This is the reality of the market we live in and if Microsoft did not target those developers, there will undoubtedly be another vendor who is more than happy to cater to what some argue is 98% of the development market. This isn’t going away until the software industry is regulated.
- What about Entity Framework precludes Persistence Ignorance? Are you actually proposing that your database entity model and your Domain Model should be one and the same? To me no matter what O/RM solution you are using, you are leaking too much of your storage implementation into your Domain if your entity model and domain model are one and the same. At the other end of the spectrum (the UI Layer), many agree that your domain model and your presentation model in complex scenarios should not be the same, because presentation is a different domain than your business domain. In the same regard persistence is a separate domain from your business domain.
- If you agree with me on point 2 then point 3 is moot. Your business objects are not tied to your entity objects. So you are free to test them with out being connected to the database.
What I’m saying here is that you should think of your data layer as a separate domain in and of itself from your business layer. Once you make that leap, you’ll see that the arguments against Entity Framework are unfounded because it presumes that your business layer and entity layer are one in the same.
If that argument is not compelling enough for you, ask yourself this one simple question: which would you prefer to maintain, an application built using datasets to the form, on one built with EF objects to the form?