Despite making a decent living with Microsoft products, writing software using their tools, and having been recognized as a Microsoft MVP for a bunch of years, I am not a Microsoft minion. I don't rush to every bright and shiny new technology they spit out, and I'm not afraid to say where I think they screwed up. I use the technologies that make sense for me and my clients and try to keep up enough to know what I want to learn and focus on in the near future. And if one of their competitors has a better tool or technology, including their open source competitors, I'll use that instead of the Microsoft offering.
In other words, I'm probably a fairly typical developer who happens to mostly use Microsoft tools. And I'm not an architect, just a common coder who tries to write good applications. So I don't have or use any highfalutin ideas about perfect enterprise architectural stuff.
With that background, let me explain why I've not been using Entity Framework, other than for trivial applications and a few sample applications that appear in software development courseware that I write. I'll be blunt: On first meeting, Entity Framework seems like an over-engineered, bloated data-access technology designed for huge enterprises, not the small clients I mostly work with, nor for the smallish utility sites I develop for myself and groups I belong to. It feels like just yet another data technology that spews from Microsoft every year or two that is in search of a problem, embraced by a select few who never seem to ship products. It generates bad dynamic SQL that is a nightmare for DBAs and sucks performance out of a database server (see Simon Sabin's blog to see some of his exploration of these issues).
Whew. Okay, not all of that was kind or even fair, but it felt so good to type it! But the Entity Framework really does have the feel of a huge bloated beast that sits between my code and the data, sucking performance out of every component in sight. Sure, it lets me write some slick LINQ code in the middle tier of my applications (okay, and sometimes the user interface tier), doing what it really is: an object-relational management system that saves me writing tedious mapping code in my middle or data access tiers.
Microsoft generates new data access–related technologies like there is no tomorrow. I'm still a lot more comfortable sticking with a single technology in my middle or data access tiers, as appropriate: raw ADO.NET. Even the ASP.NET data source controls just seem to get in the way and complicate things way more than necessary, causing me to write more code rather than less. Raw ADO.NET code that hits stored procedures results in applications that are simpler, cleaner, and perform better. Granted, they might be a little more work to write and maintain, but not much in most cases.
Or am I just getting old, stuck in my ways? Not too much, if the technology I'm in a rut with is barely 10 years old!
Part of where I'm coming from is that I was badly burned by a code generation technology a few years back that directly contributed to the failure of two large projects. There were, of course, myriad other reasons for the failures—and I'm not blameless—but the technology and the middle tier it created was certainly a starring role. So I'm leery of putting big and bloated between my code and data. Any technology has to work hard to earn its place there.
Another reason I'm leery of Entity Framework is because of the LINQ to SQL fiasco. LINQ to SQL came out some a few years ago, described on MSDN as providing "a runtime infrastructure for managing relational data as objects without losing the ability to query." It only worked with SQL Server, but that's where most of my data lives so that isn't a limitation. It was fairly simple, exposed most of what I needed from the database (more so than what Entity Framework 1 provided), has nice tool support in Visual Studio, and the classes make sense to me. It was a great way to get started with the LINQ features built into C# and VB, and applications didn't seem to suffer from its presence. Sure, it doesn't have as robust support for the object side of ORM, but it was a nice tool and I used it in a few applications.
Then, suddenly, LINQ to SQL was apparently deprecated in favor of the Entity Framework. I don't claim to know all the reasons or understand the internal politics of it all, and I've not seen a formal announcement of this, but LINQ to SQL sure doesn't get the love from Microsoft these days that the Entity Framework does. Which means LINQ to SQL will likely stagnate. So these days I'm not very trustful of Microsoft and their long-term dedication to technologies. It's a feeling of betrayal.
And yet another reason to be leery of Entity Framework is that it is already a huge, complicated beast, and I have no confidence that Microsoft can resist the temptation to add ever more features to satisfy the whim of every customer. Their track record is not stellar in this regard.
I have to admit that my feelings about Entity Framework have been tempered rather substantially by Julie Lerman's passion for the framework. Some of my concerns about Entity Framework's complexity were confirmed as her first book about Entity Framework blossomed way beyond its original projected length (it now weighs in at over 800 pages). But when someone that smart is so passionate about something, I begin to doubt my own assessment. And now that she is putting in all the blood, sweat, and tears for the second edition of her book, I have to believe that the passion has not waned. Perhaps I've been wrong about Entity Framework?
Why Entity Framework Now?
So with all of this bad blood between me and Entity Framework—real and imagined—why am I considering it now for new applications? Well, one of the easy answers is that it seems to be all grown up in its second iteration, formally called Entity Framework 4.0 to sync up the versioning with .NET 4.0. My number-one top favorite new feature is support for foreign keys, in the form of a new type of association. I realize that there are those who think that the conceptual model is corrupted by foreign keys, but I just can't see living without them.
Second on the list of my favorite enhancements is the improvement in the SQL code that the framework generates. It still is not going to endear developers to the DBAs who have to support the databases being pummeled by Entity Framework-generated code, but it's getting better. And I certainly acknowledge that this is probably one of the hardest features to implement in Entity Framework, producing solid SQL in response to complex LINQ statements going against complex relational data, and making it all reasonably generalized. (You can read more about the improvements in Entity Framework 4.0 in Somasegar's blog entry here.)
The design tools integrated in Visual Studio 2010 also seem to be better, but time will tell whether they expose enough features to mask the complexity of building and customizing Entity Framework models.
But three things are really drawing me to Entity Framework 4.0:
- The apparent death of LINQ to SQL
- The simplicity of writing LINQ statements in code against flexible object hierarchies
- Speeding up development time
I know, some of these are making me face my previous Entity Framework demons and betrayals. And it is still likely that Entity Framework is overkill for most of the applications I write. But for applications that are reasonably data-heavy, it certainly does an awful lot of the heavy lifting for managing application interactions with data. Even I find it a bit tedious these days to constantly new up a SqlConnection object, define a SqlCommand, and work with the resulting DataReader or other object, then do it all again to persist data changes.
A few other things have softened my stance on Entity Framework as well. I'm doing a lot of ASP.NET MVC 2 development, and the Entity Framework works quite well as a foundation for the model part of the application. I'm not as leery of dynamic SQL as I once was, although I'm aghast at the security problems it can cause if not handled very carefully. (My friend Peter Debetta of Wintellect, with his cursed Safe Dynamic SQL presentation, is a big part of my softening stance on dynamic SQL. I'm not fully convinced, but Peter makes a good case that it can be done right by us common coders.) And frankly, faster development time is an alluring temptation, particularly using a fairly thoroughly debugged and theoretically proven object framework. It also helps that performance is usually not a huge concern in my applications, because of their nature.
So, I'm open to Entity Framework as I've never been before. And I've learned that when one opens oneself to the universe, interesting things happen. Universe, bring it on!
References
Simon Sabin, a Microsoft SQL Server MVP, has worked with Entity Framework and looked at the SQL code it generates. The link below has references to the blog posts he has written about the problems:
- Simon Sabin UK SQL Consultant's Blog
- Somasegar is the Senior Vice President of the Developer Division at Microsoft, so he oversees all the cool tools we use to create applications. Here is his recap of the enhancements in Entity Framework 4.0:
Entity Framework in .NET 4. - James Johnson has started a series on Entity Framework on Simple Talk. Based on the first installment, this should be a good series if you're new to the technology: Hands-on Entity Framework.
