Chapter 15 — LINQ to SQL and ADO.NET Entity Framework

Bob Beauchemin’s (Blog) chapter on LINQ to SQL is the most succinct, accurate and informative information that I’ve found on this topic.  I have clients that use linq to sql and EF exclusively and others who don’t use it at all.  I believe that trend will continue for the forseeable future.  One of the questions that I’m often asked by DBA’s is something along the lines of “How do I justify to the development team that stored procedures is the ONLY way to go?”  Oddly, from the development manager or the product champion I’m asked “can you please explain how much better the Entity Framework is to the DBA group”?  Clearly there are absolutely valid considerations on both ends of the spectrum. 

A few months back, I blogged about technical debt and how crippling it can become in an organization.  More often than not, folks I interact with think about technical debt when it comes to purchasing a new system to replace the one that exists but never de-commissioning the older system… while that’s certainly a form of technical debt, the one that I find the most pervasive is the one that companies have the ability to stop. 

It’s as simple as architecture and design.  Let me re-phrase… it’s as simple as consistent architecture and design. 

There are many design and architecture decisions that will be made over the course of the product or service that you are developing.  The one thing that many of them will have in common is a database.  For this reason alone, the method that your company or your product accesses that database needs to be consistent. 

While I certainly have an opinion on how I’d prefer to see things, I’m well aware that it’s due to my level of comfort and expertise and not always in the benefit of the client, the product or the solution being sought.  There are times when the speed of the database is not of the utmost concern.  In the scenarios where performance is crucial to an application I prefer modularized design elements closest to their native source.  In the event of the database, this would call for stored procedures versus any other method of accessing data.  Similarly, if the application needed to send tens of thousands of e-mail notifications per day, I would not opt for sql mail even though I could write the code necessary very efficiently and quickly. 

It’s critical to accept the changes that are continually going to happen, learn to work within the changing paradigm of what is versus what was and the benefactor will be your company, your own knowledge and perhaps even your sanity.

Thanks again Bob for such a great chapter.  This is one of those subjects that I’ve found to be wrought with passion, sincerity and unfortunately ignorance.  Your chapter is a must read for anyone who’s unsure of linq to sql or the EF framework… and a word out to the DBA’s who are on the fence (much like I was a few years ago), check out .net 4.0.  There are some exciting changes with respect to re-usable query plans and parametrized query handling.


0 Responses to “Chapter 15 — LINQ to SQL and ADO.NET Entity Framework”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 11 other followers