I'm one of the signatories to the infamous Entity Framework Vote of No Confidence. Back then, the Entity Framework was being released by Microsoft, punted as the solution to all our problems; the reality was different. It was as if the ADO EF team had come out of 'varsity in the 90's, all fired up by the success of Enterprise Java, and determined to duplicate that success. The movement of the industry away from bloated ORM's seemed to have passed them by. The Repository pattern, POCO's, Domain Driven Design; all were foreign concepts to the Entity Framework.
Happily the situation has improved dramatically, so I took it upon myself to do my POC for my latest little project using EF. My experience was not a happy one. The designer was great; albeit suffering from the same problems as the Linq to SQL one:
- Difficult/Impossible to merge in Source Control
- No automatic renaming available, so I had to go and rename properties all over the place
- Constant regeneration required, see above point for an idea of frustration levels
But to be fair, the designer was not worse than the Linq to SQL one, and in fact was quite a bit nicer to use. I don't know that "has the same major glaring problems, but is nicer overall" is a compliment, but hey.
Now we move on to the usage of the code. I tried, I really tried. I wanted a POCO class, free of EF-specific artifacts (well, attributes are okay, but that's it). I selected the "ADO.NET C# POCO Entity Generator" template. I then had a look at the generated code, and nearly spilled my coffee.
THIS is Microsoft's idea of POCO? I mean, I can see where they're going, but my word, there's a lot of crud in there. What the hell are those bloody FixupCollection things? And I must admit I tossed the whole thing there and then.
But, a little research and checking later, and I had to reconsider my position. It turns out that you can use your own code no problem, you can use List as your association property if you want. What I had seen was not the "One True Microsoft Way (TM)", of doing things, but instead an implementation they suggested. One implementation possibility of many.
So, I've resolved to give EF another try, but as things stand here are things I still don't like:
- That bloody EDMX file, for the same reasons I hate the DBML file.
Solution: Same as in Linq to SQL, hand code your own classes.
- I don't like having to declare my association properties as virtual. Hardly POCO if you're being forced into coding decisions you wouldn't have made otherwise.
Solution: Suck it up and live with it. It's not the worse thing I've ever done for an ORM.
- Being forced into using the visual designer in addition to my POCO's. With Linq to SQL I could add the attributes to my classes, and had no need for that blasted file. I know, I know, if you're adding repository-specific attributes, it's not true POCO, but I can live with attributes. With EF I don't have that choice anymore.
Solution: Use Linq to SQL, code my own POCO T4 Template, or live with it.
None of those are severe enough for me to continue saying no to EF, but they do contribute to a general unhappiness. I LIKE Linq to SQL, but I must admit that EF is getting closer and closer to matching what I like about it, and adds a whole slew of extra goodies as well.
If a dyed in the wool EF skeptic like me can slowly gain a grudging acceptance for the technology, I guess they've really done their job very, very well in EF 4.0. I never though I'd ever say this, but I'm actually looking forward to using EF in my next project.
Looking for a Document Management System? Signate 2010 is powerful, secure and easy to use.