How to design your data connectivity strategy

I’m scurrying at lunch to finish reviewing some architectural guidelines for the P&P group (I’ll be done today, I promise).  I stumbled across a section with the same title as this blog post.  I’ll answer the question concisely:

Pull an existing persistence tool off the shelf, make sure you understand it, and code, code, code!  Persistence coding is a commodity in this day and age, so just use and existing tool and get on with your project.  It’s extremely unlikely that there’s any business advantage to writing data access code by hand when there are so many existing tools out there.  I’ll repeat this little gem one last time, if you’re writing ADO.Net code by hand, you’re stealing from your employer or client. 


About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Bart

    I have found this blog today and have been browsing through the titles with a lot of enthusiasm. Until I came here. I cannot disagree more. I have been using Microsoft SQL Server and ADO since 2001 (and ADO.NET since 2003). Oh yes, I have also been using ORMs for a few years now and I still hate them just as much as I hated them back then. IMHO, when switching to an ORM, you are just switching to a different set of technical issues… Since I do care about performance, network bandwidth and memory usage, I will stick with ADO.NET as long as I can. I can throw data around using ADO.NET and advanced SQL querying in a way that cannot be equalled by any ORM. Period. If this is not the case for most of your readers, that’s not my problem, but if you feel right to implicitly call me a thief (which I find quite extreme), I will call you incompetent and prejudiced in my turn. Happy developing.

  • jdn

    As I like to say, abso-freaking-lutely.

    Even if you are in a stone-aged environment that questions the use of an ORM, use the second worst possible option and use Enterprise Library. It’s better than it used to be.

    If you find yourself ever coding SqlConnection conn = new SqlConnection() (etc.), you should reconsider.

  • Mike Griffin

    Not trying to spame here but Jimmy asked have a look at EntitySpaces.

  • Jeremy D. Miller


    Your comment exposes a point that I missed before. Even if you *have* to use sproc’s, you can still pick off existing code like iBatis.Net or the data access stuff in EntLib to do the repetitive ADO.Net grunt work.

  • Brad Mead

    Yes! I had the awful experience recently of defending ORM technology by someone who had worked on “real” database systems and thought the idea of judicious data access was a SP-only affair. After explaining that I had heard and debated regarding performance considerations (execution path caching… yada yada) and that it appeared that ORM tools were mature alternatives to direct manual database-level TSQL programming — I was cynically dismissed offhand. What’s more this all from a glory hound personality who “didn’t have time” to hear alternatives or give them an audience.

    Aye yie yie!

    To all who participated Oct5th 2006 thanks again for making it happen (esp the enabling sponsors).

    Pragmatism was reinforced and my perspective about entertaining alternatives and channeling passion toward subjectively proven principles remains steadfast.

  • Jeremy D. Miller


    All it amounts to is how many different data access frameworks are out there that already do connection sanitation, error handling, and data marshaling. There’s no justifiable reason to roll your own data access layer in the mass majority of circumstances.

    My team uses NHibernate off the shelf. We have about 3-4 lines of ADO.Net manipulation in some test automation code, and that’s it for the entire system so far.

  • Jimmy Ford

    Maybe I’m a newbie…… Hold on, I am a C# NUB so I didn’t quite get the, “if you’re writing ADO.Net code by hand, you’re stealing from your employer or client.”
    One of our developers is about to start a connectivity project so I’m quite interested if something can be done easier. Or am I totally lost here?

  • http://scottschecter Scott Schecter

    I couldn’t agree more!