Redmond Review

The Value of Known Entities

• By Andrew J. Brust
• 09/01/2009

Since the birth of Visual Basic and Access, Microsoft has burned through a series of data-access APIs. Until ADO.NET, none of these APIs was dominant for more than four years. But seven years after ADO.NET was released in 2002, it feels like change is overdue. Now Microsoft is promoting Entity Framework (EF) as the new data API of choice. But does EF pass a simple regression test?

Microsoft insists that EF delivers a real improvement to developers. According to Redmond, EF resolves the "impedance mismatch" between relational data structures and object-oriented programming, as well as the paradigm digression this mismatch causes for developers. With EF, developers can finally stop switching into a mindset of tables, columns and set-based queries and instead remain focused on classes, objects and properties. Developers can, in effect, treat the database as a black box, and EF as a layer of abstraction over it, with the familiar ADO.NET functionality retained underneath.

Breaking What We've Fixed?
Still, core ADO.NET is an intuitive model that gracefully bridges the world of SQL and set-based data access with that of programmatic, procedural processing of data. It works not just with SQL Server but with most other database platforms as well. It can abstract data into typed DataSets or work directly against the database in a connected fashion. It provides precise control over how data is queried, either directly or through stored procedures, including those which return multiple result sets.

Despite EF's dependency on ADO.NET, it lacks much of the latter's core capabilities. EF can be made to work with stored procedures, but I see that as an afterthought and not a key scenario. Some debate the value of stored procedures, but in many corporate environments, there's no debate allowed: security concerns mandate that stored procedures are the exclusive interface to data. EF also forces Microsoft developers to wait patiently while, once again, other database vendors implement support for a new Microsoft API. This isn't happening quickly, and I have it on authority from a major vendor wishing to support EF that Microsoft's documentation isn't helping matters. Then there's EF's SQL code generation. Not only are the queries often overly complex, but I also question the notion that a declarative query language should be generated like low-level byte code.

Even if you find object-relational modeling compelling, there are features missing from EF. Much of this will be addressed in the next version. Things like model-first and code-only development will allow developers to be less reliant on the EF designer's interpretation of entity schema from existing table schema. The EF team is trying hard to have a transparent design process-and, I must admit, they're doing an excellent job. The new features look to be robust and in tune with what EF customers are requesting. Even EF's SQL generation is being optimized. But by the time these features are available and used by developers, they still won't address the key issues I've enumerated here-and they'll probably negate the efficiencies that were the underpinning of EF's creation in the first place. Check out the EF team's blog post on planned code-only improvements at http://tinyurl.com/mans6k. I'll let you decide whether they'll reduce complexity or add to it.

For the Greater Good
For dev teams that control the code and the database, such as ISVs, EF may be a good option. EF may also be a good fit for Microsoft's internal use, which is probably why ADO.NET Data Services and ASP.NET Dynamic Data both use EF.

But I question how well EF serves the majority of developers who enjoy the power of relational technology and want access to it. Such developers want to write their own queries, or may want to let their DBAs do so and then call the stored procedures that result. These developers appreciate the cooperative diversity of programming and relational query; they're not "impeded" by the distinction between them, nor do they see a mismatch.

EF should add to this diversity, not pave over it. It provides a nice solution, but to something that isn't everyone's problem. Microsoft needs to make EF work for the mainstream, or it needs to tone down the rhetoric that the mainstream should adopt it. If neither is done, Microsoft and ordinary developers may have an impedance mismatch of their own.