Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
You'll have my SQL when you pry my keyboard from my cold dead hands

image Background - Some people don't like the Entity Framework, some do.  Many see the need to blog about it.  You can guess the rest, or JFGI if your need more info.

The debate is nothing new; we have databases that are really good at storing data, searching that data, and spitting it back up.  Problem is the format spit up doesn't play well with how we use the data in code.  So we write some code to translate from one system to another.  If you want to be fancy, call it Object Relational Mapping.  JFGI as ORM if you want.

Any skinned cat will tell you, there is more than one solution to a problem.  That's not a problem, that's called choice.  A problem is when one two sides argue over different solutions so loudly you cannot hear what they are saying.  It's often overlooked that there are more than the two options present.

I write all my SQL.  I use a good deal of strongly typed DataSets.  I write my ORM code.  I have no problem with this, and have good reasons for doing such.

First, I know SQL really well, and more importantly I understand how to manage a database.  I'm not a DBA - I've never setup a quad-node cluster with latency-free fail over across multiple data centers - but I know how to read a query plan and setup an index.  I have over a decade of experience with setting up a database behind and optimizing the system - I see no point in tossing that hard earned experience away.

Second, and this is probably the most important factor, your ORM doesn't matter.  Your framework doesn't matter.  Your language, IDE, and ergonomic mouse you paid way too much for, don't matter.  When the servers start coming down, it's IO.  Disk or network bottlenecks are killing you.  We have the RAM folks, and the clock cycles are so plentiful we have to invent new ways of writing code just to use them all.  When all hell has broken loose, you need to know how your code works with the underlying IO; the fact you concatenated a few strings inline instead of using StringBuilder doesn't amount to a hill of beans.

So what do you take from this?  ORMs are evil and true ninjas master SQL?  No.  You take from this that no matter what you use, it is 100% your responsibility to understand how your platform works at the IO level and how to adjust it when needed.  You take from this that you pick a tool based on you and your teams comfort level with that tool, and you don't bother to get caught up in pointless saber rattling posts like this one.

If this has you all worked up, well... you can STFW for "kittens" or something.

Posted 06-27-2008 6:27 PM by Michael C. Neel
Filed under: ,



Scott Bellware wrote re: You'll have my SQL when you pry my keyboard from my cold dead hands
on 06-27-2008 9:01 PM

We have a huge problem of perspective in the software industry, but it's quite a bit more common in the Microsoft space: choosing tools for the comfort of the team is an important optimization, but it's one of the least-valuable optimizations we can make, and unfortunately it's an optimization we make too often.

The tool has to fit the architecture, and the architecture is a representation of requirements as expressed as a whole mess of constraints.

Tools are certainly relevant, especially to teams who choose the wrong tools for the requirements, and end up imposing arbitrary limits on their capabilities that were not clear at the time the tool was chosen.

I think it's important to note here that "ORM" is part of the general software pattern language.  It means something.  It has a colloquial definition that is well-understood in the industry.  As a meta pattern, ORM implies certain constraints and architectures.

On a number of occasions, the Entity Framework team have intimated that they don't see the Entity Framework as an implementation of ORM.  So when our requirements suggest that we can benefit from ORM, the tools we choose to fit those requirements must jive with the semantics of ORM.  Entity Framework doesn't provide a good fit for problems that are best served by ORM.

If you don't know the capabilities of the tools you're putting into play, and you're not aware of common misconceptions of the tools that you're considering, the project, the team, and the business is going to suffer unnecessarily.

Entity Framework is not an adequate fit for ORM.  The Entity Framework team has suggested this.  Experts in ORM in .NET and in general have observed this.  Yet, we're still talking about Entity Framework in terms of solutions for ORM problems.  This isn't a matter of architecture then, it's yet another instance of influence and marketing.

Using RAM matters, but it's not a default architecture.  There are no universal default architectures.  Architecture is contextual.  When the architectural constraints are better served by an approach other than memory-based access, then we're ethically bound to serve those constraints with the right choices.

DataSets where DataSets serve, ORM where ORM serves, Lucene where Lucene serves, map/reduce where it serves, and so on.

You may be right that your framework doesn't matter.  But when it does, you'd better know if your framework is a framework, or a theoretical proposition of a potential framework that may exist in some future version.

» You'll have my SQL when you pry my keyboard from my cold dead hands A C One: What The World Is Saying About A C One wrote » You'll have my SQL when you pry my keyboard from my cold dead hands A C One: What The World Is Saying About A C One
on 07-02-2008 10:18 AM

Pingback from  » You'll have my SQL when you pry my keyboard from my cold dead hands A C One: What The World Is Saying About A C One

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)