I came across this article
refuting a marketing like article by one of the EF team members.
After using NHibernate for a while and looking into JPA and old JDO on the Java world, I don’t think I’ll get my hands on the EF any time soon, if I can avoid it.
Why? The main reasons are summarized on this site:
I will mention the most compelling ones to me:
- Main focus on the data aspect
- Lack of Lazy loading, hydration, dirty flagging
- Lack of persistence ignorance…The tight coupling of the persistence infrastructure to the entity classes largely eliminates the ability to efficiently use very tight feedback cycles on the business logic with automated testing.
As Peter Ritchie summarizes on his comment:
…if I’m a traditional TDD methodologist (for lack of a better term) and I’m building up my code base with test-first mentality then it’s all about the code. The automated tests are used for documentation of things like requirements, user stories, etc. Agile folk try to avoid documents like conceptual models, our conceptional model is the code, it’s our classes. I don’t need another conceptual modeler and I don’t need to have a modeler create new classes for me, I don’t need it to modify my classes, the classes I’ve defined for my application do exactly what they need to do.
As we build up our classes to reflect what the domain is, as we know it now, we eventually want to add the ability to persist those objects to a store of some sort. It’s at that point we being to think of OR/M. But we want to keep that persistence separate from our abstractions, keeping true to the single responsibility principle and separation of concerns. All the trappings of persistence are abstracted somewhere else.
Just my opinionated opinion…I have the gut feeling EF is sending ADO.NET back to the 1.1 version with Typed DataSets that were mere replicas of the database schema…
Ignorance is bliss and in this case persistence ignorance is a bliss I won’t give up on.
