Jeremy D. Miller -- The Shade Tree Developer

Sponsors

The Lounge

Syndication

Recent Posts

Tags

View more

News

Blogs I Read

Archives

Advertisement

Jeremy D. Miller -- The Shade Tree Developer » How to design your data connectivity strategy
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 imagehelp@codebetter.com
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. 

 

Posted 11-07-2008 1:06 PM by Jeremy D. Miller

[Advertisement]

Comments

Scott Schecter wrote re: How to design your data connectivity strategy
on 11-07-2008 2:12 PM

I couldn't agree more!

DotNetKicks.com wrote How to design your data connectivity strategy
on 11-07-2008 2:20 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Jimmy Ford wrote re: How to design your data connectivity strategy
on 11-07-2008 2:29 PM

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 ADO.net connectivity project so I'm quite interested if something can be done easier.  Or am I totally lost here?

Jeremy D. Miller wrote re: How to design your data connectivity strategy
on 11-07-2008 2:41 PM

@Jimmy,

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.

Brad Mead wrote re: How to design your data connectivity strategy
on 11-07-2008 2:56 PM

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 wrote re: How to design your data connectivity strategy
on 11-07-2008 3:16 PM

@Brad,

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.

Mike Griffin wrote re: How to design your data connectivity strategy
on 11-07-2008 4:39 PM

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

http://www.entityspaces.net

jdn wrote re: How to design your data connectivity strategy
on 11-07-2008 8:34 PM

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.

FreePress Blog » GR Shared Link - How to design your data connectivity strategy wrote FreePress Blog » GR Shared Link - How to design your data connectivity strategy
on 11-15-2008 12:12 AM

Pingback from  FreePress Blog » GR Shared Link - How to design your data connectivity strategy

FreePress Blog » GR Shared Link - How to design your data connectivity strategy wrote FreePress Blog » GR Shared Link - How to design your data connectivity strategy
on 11-15-2008 3:01 AM

Pingback from  FreePress Blog » GR Shared Link - How to design your data connectivity strategy

Ayende @ Rahien wrote Stealing from your client
on 11-21-2008 7:24 AM

Stealing from your client

Been Caught Stealing « Infovark Underground wrote Been Caught Stealing « Infovark Underground
on 12-18-2008 8:44 PM

Pingback from  Been Caught Stealing « Infovark Underground

Add a Comment

(required)  
(optional)
(required)  
Remember Me?