Redmond Review

The Value of Known Entities

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 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.

About the Author

Andrew Brust is Founder and CEO of Blue Badge Insights, an analysis, strategy and advisory firm serving Microsoft customers and partners. Brust is also a Microsoft Regional Director and MVP; an advisor to the New York Technology Council; and co-author of "Programming Microsoft SQL Server 2012" (Microsoft Press, 2012). A frequent speaker at industry events, Brust is co-chair of the Visual Studio Live! family of conferences and a contributing editor to Visual Studio Magazine. Brust has been a participant in the Microsoft ecosystem for over 20 years, and has worked closely with both Microsoft's Redmond-based corporate team and its field organization for much of the last 15. He is a member of several "insiders" groups that supply him with insight around important technologies out of Redmond. Follow Brust on Twitter @andrewbrust.

comments powered by Disqus

Reader Comments:

Tue, Feb 25, 2014

Of course I don't lead a large chcurh, but I can see where the sometimes pain of ministry and the never ending demands could drive you into a closet relationally speaking. There is also something about leadership that sort of alienates you somehow. I can't explain it. I try very hard NOT to let that happen but I think it might be somewhat unavoidable because of how others view you. (not something you do)My ministry team is full of good friends. I try to do things together as a team and also just for fun - like going to the movies tonight with some girlfriends or having some couples over for dinner or just going to lunch. We don't have as many couple friends as I'd like though. And yes, we stay involved in a life group.I also have relationships with others outside the chcurh - not a ton of close ones, but some. I feel very able to be myself with them and not wonder about their opinion of whatever is going on at chcurh. Hearing people's opinions sometimes makes me want to run and hide!The rub for me has been that some people are good friends, but I also lead them. The stress of - at times - them being upset with Jan the leader takes a toll on the friendship. I don't know what to do about that. [url=]snqpumu[/url] [link=]pgmyhyczsfq[/link]

Mon, Feb 24, 2014

I take my cue from Jesus in the garden. He shows up just how imaoptrnt intimate relationships are. He was in a time of extreme pain, about to go to the cross and chose to open himself up to imperfect people. He just wanted them close by. He wanted Peter, James and John to be there with Him even though there was nothing they could do to change the outcome of what was about to happen to Jesus and Jesus knew it. Despite that He tried three times to wake them because He wanted people there when He hurt. If He didn't He would not have tried over and over. I mean He was the Son of God and needed people so I guess we do too.As ministry leaders we have often been trained to give people an impression that we are good all of the time and we pull away from people so they do not se our humanity. The whole never let them see you sweat scenario. But that is not real life. If Jesus thought it was ok to let people in who were imperfect (and about to deny Him) then I think it is ok for me to have friends close in who see the real me and it be ok. They will let me down at times and I them, but it is worth it.So to sum it all up. We need to know the difference between a Peter and a Judas. Sometimes we throw people into the Judas category because we have been hurt before and that is a mistake, they might just be a Peter who does some dumb stuff but really is true blue and just in need of some maturity. On the other hand we put Judas' in places we shouldn't because we don't use discernment in our relationships. We let the wrong people in.We cannot withdrawal from people because of fear even though it is tempting at times. We just don't want to risk it sometimes. But, God is much better at protecting me that I am at protecting me. I am going to continue to let Him do His job as our church grows and try to not withdrawal when I am tempted too.

Fri, Nov 20, 2009 John Illinois

Perhaps, a strategy for using EF is to build initially in EF and then, based on performance testing, revert back to ADO.Net on a granular basis to solve performance the performance hits.

Fri, Oct 9, 2009 Scott Slack Redmond

How about if MS releases a great OO DBMS for those of us who find the Relational model to be arcane, and free us from the ORM pain.

Wed, Sep 23, 2009 Seamus Steeler Country

Evan, ORM's, Object Relational Mapper, have been around for many years. Microsoft is very late in providing the Entity Framework and it is, unfortunately, immature. NHibernate is one of the more popular open source ORM's used by many MS shops. It is a port of Java's Hibernate. There are many others both open source and commercial. I will say that my company uses NHibernate and in my opinion it hasn't given us anything. It has not reduced the time needed to implement or maintain the data layer nor has it provided much benefit over manually mapping data retrieved from a db to an object or a collection of objects and implementing our own cache schemes. It most certainly hasn't helped performance. Configuration of NHibernate has a steep learning curve and we find ourselves constantly fighting with it's features. For simple or straight forward systems it may be fine. But I have never worked with simple systems except for samples. In any case, ORM's are very interesting and you should certainly learn more about them.

Fri, Sep 11, 2009 jp new jersey

"But seven years after ADO.NET was released in 2002, it feels like change is overdue." You need a new version because it "feels like change is overdue"? Is there something missing from Is there something you need to do today that you can't do with SQL and I think we can all benefit from a mature, fully developed data access api. Too many times in the past we had to go from something that worked fine to a half-developed api and had to use the old api to fill in the gaps. Let it rest.

Fri, Sep 11, 2009 Hank Fay Kentucky

You've gotta love that "impedance mismatch" phrase. But guess what: without jumping through hoops, any ORM-by-any-other-name is going to gloss over distinctions easily discernible in the raw data model. The idea that a class structure should model a data structure is a concept born of statically-typed languages. Give me the direct data access of Visual FoxPro (which reaches end-of-normal-support on 10Jan2010) anyday. Well, give me the version of VFP compiled to .Net being developed by eTecnologia, actually, because then I have the best of both worlds. My classes express business rules, not the data structure.

Thu, Sep 10, 2009 WTW So. Calif.

Evan writes: "SQL is already a powerful/versatile language". Powerful and versatile, yes, but intuitive or OO friendly? Not at all. It's a follow-on from 1960s-era RPG style programming! And the relational model itself was and is a kludge developed to makes it easier to implement the database system, not to use it. It succeeded mainly because it was so much more efficient than the awful hierarchical database IBM had devised, and then took on a life of its own. But its efficiency of storage and retrieval masks the hoops we all go through to utilize it. The LINQ syntax, very similar to that of semantic database systems developed in the 1980s, is not only a better fit for modern OO languages, it's actually a more intuitive (and less error-prone) way to query and update data. So it seems that MS has done exactly what you request - provide "natural tools for helping the developer create... queries". It's just that, since relational systems are so "un-natural", that takes some doing. [Now, if we could just convince those VB & Access programmers to stop putting their data access code in the UI layer, and properly structure their programs... :-)Everyone should know by now to wrap whatever DB access you use - EF, ADO, SQL, XPath, whatever - and NEVER call it directly!]

Thu, Sep 10, 2009 Evan Barr California

I never understood why Microsoft works so hard to put more layers between developers and the database. SQL is already a powerful/versatile language that is common to most relational database engines. Developers who don't have SQL experience would be better served if Microsoft provided natural tools for helping the developer create the queries instead of adding an inefficient API.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.