I feel I need to respond to the “Vote of No Confidence” on the Entity Framework.
I have little interest in petitions. They are by nature backwards looking. To get a group of people to sign onto something they have to either understand it or be driven by the charisma of the leaders. In this case, I assume the first. The contents of the petition must be stable and old enough that everyone has worked out the details. That’s the case with all the technical petitions I can think of, although admittedly that’s just a handful like the VB6 petition.
When it comes to the appalling scenario where we have at least 14 major categories of data access strategies in use in new projects today, we need the Microsoft teams to look forward and be creative in combining the best set of techniques – NOT pick one of the existing strategies and latch on to it because it came from the group that yelled the loudest.
Entity approaches are good because they better separate the business and data sides of our middle tiers. But they are also inherently difficult and inaccessible to most programmers. Entity Framework’s goal must be to bridge this gap. That means being extremely creative in picking its battles to reach toward the real world developer – not copy a strategy that is available to that developer today and fails (the combination of NHibernate and other tools used in a specific style of development). The failure is not because NHibernate is an Open Source tool. It’s not because people don’t know about it. If it worked in the majority of shops it would burn through our industry like wildfire. Why don’t you use them? Because they do not fit your development environment! This is not an easy problem that someone’s solved and Microsoft is looking the other way. It’s an incredibly hard problem – how do I know? I’ve been working on occasionally novel solutions to the problems for 20 years.
Entity Framework has issues. This is not news. It’s not even news to the Entity Framework team.
- EF is not a failure because it doesn’t fit TDD development
- EF is not a failure because business logic goes into partial classes
- EF is not a failure because it treats data as an important part of biz objects
- EF is not a failure because it accepts that most people do data first development
- EF is not a failure because lazy loading is hard – lazy loading can destroy performance
- EF is not a failure because its design tools are 1.0 level
- EF is not a failure because it has a poor strategy for merging into source control
All of these are potentially issues, but it’s critical, essential, I cannot yell this loud enough – Entity Frameworks must not be designed for the group that is best organized and screams the loudest. This already happened once with the disastrous IPOCO attempt that helped no one and wasted a lot of manpower that could have improved mapping and provided better metadata.
But then I’m sort of caught in a corner, because an important point of the petition is correct. Be cautions with EF. Do not jump into Entity Framework because of Microsoft marketing. It’s a tough platform that will get a little easier when the current spasm of books comes out. The niche is pretty narrow and if you step off the boards, the quicksand can be pretty deep. Treat it like what it is – an amazingly large and complex project that is being released as a 1.0 product. It’s an infant. The metadata and mapping still stink. Look at it as Microsoft’s current future direction, but remember how many current future directions we’ve had over the last 15 years (around ten) and remain skeptical.