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.