Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

O/RM Vs Stored Procedures. Which is the best approach?

For the last few years, many developers and architects are engage in a series of debates about ORM Vs Stored Procedures. Many of them argue for ORM and others are arguing for stored procedures.  The interesting thing is that people with highly object orientation sense, recommends ORM. The J2EE community strongly recommending the ORM approaches instead of using stored procedures. Some .NET developers coming from Visual Basic 6.0 background supports stored procedures. Hibernate and NHibernate (.NET version of java version Hibernate) are the highly successful ORM that using both .NET and J2EE community. Then which is the best approach for data persist? Personally I hate stored procedures and strongly recommend for ORM instead of using the legacy stored procedure programming. 

Why I hate stored procedures?

Stored Procedures are written by DB languages such as PL/SQL and T-SQL and this type of languages are not designed for writing business logic and debugging process is really a nightmare. And stored procedures hide the business logic and lacks readability of business process. If you are going to port DB from one RDBMS to another one, you have to re-write your all stored procedures. If you want to run your product on multiple databases, the ORM is the right approach. And ultimately the stored procedure restricts the proper business abstraction. Many people argue that stored procedure provides better performance than dynamic generated Sql from an ORM and people believed that all stored procedure are pre-compiled. According to Microsoft Sql Server documentation, Sql Server does cache the execution plan for stored procedure instead of pre-compiled. Have a look at the MSDN article Execution Plan Caching and Reuse.  And I believe that maintainability, scalability and proper abstraction are the key factors of enterprise applications. The ORM approach enables these benefits.

If you are a .NET developer, there is happy news for you. A new ORM named Linq to Sql coming from the Redmond campus along with the .Net framework 3.5.

What is LINQ to SQL?

LINQ to SQL is an O/RM (object relational mapping) of the .NET Framework 3.5. It provides you to model a relational database using .NET classes.  You can then query the database using LINQ, as well as insert, update and delete data from it. LINQ to SQL supports all types of database objects such as views, and stored procedures and also transactions. It also provides an easy way to integrate data validation and business logic rules into your data model. Visual Studio 2008 provides a Linq to SQL designer that enables to model and visualize a database as a LINQ to SQL object model. You can create the all database representations using the Linq to SQL designer. With the Linq to SQL designer, you can drag and drop the tables into the Linq to SQL designer surface and can represent the relations between tables. Linq to SQL allows you to model classes that map to tables within a database.  These classes are known as "Entity Classes" and instances of them are called "Entities".  Like other OR/Ms, the Linq to SQL OR/Ms will generate the SQL statements at the runtime when interacting with the Entity Classes.

Lets look at the below business object that mapped the customers table using Linq to Sql.

[Table(Name="Customers")]
public class Customer
{
            [Column(Id=true)]
            public string CustomerID;

            [Column]
            public string CustomerName;

[Column]
            public string City;

[Column]
            public string Phone;
}

 After modeling the Database with Linq to Sql, we can do all DB operations against it. The below code is the query against Customer object that represents the Customer table.

DataContext db = new DataContext();

var q = from c in db.Customer
            where c.City == "Cochin"
            select c;

In the above query will select customers of city Cochin .The DataContext represent an abstraction of your database.

The below code is update existing customer

  DataClassesDataContext db=new DataClassesDataContext();

  Customer cust=db.Customer.Single(c=> c.CustomerID ==”C101”);

  cust.Phone="919847059589";

  db.SubmitChanges();

The below code is add new customer

DataClassesDataContext db=new DataClassesDataContext();

Customer cust=new Customer();

Cust. CustomerName=”ABC Ltd”

cust.City=”Mumbai”;

cust.Phone=”919847059589”;

db.Customer.Add(cust);

db.SubmitChanges();

The below code is delete customer

DataClassesDataContext db=new DataClassesDataContext();

Customer cust=db.Customer.Single(c=> c.CustomerID ==”C101”);

Db.Customer.Remove(cust);

The below code is using a join query

var orders =
from o in db.Orders
join c in db.Customer on o.CustomerID equals c.CustomerID
where c.CustomerID == "C101"
select new {c.CustomerName, o.ShipName, o.ShipAddress };

Linq to Sql is an exciting ORM tool from Microsoft and I hope that people will use this ORM along with .NET 3.5 applications.

Published Wednesday, March 26, 2008 11:45 PM by shiju
Filed under: ,

Comments

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Monday, June 30, 2008 4:28 PM by trythis

Try creating the customer outside the context and add it later.. then you realize.. did Microsoft forget to tell me that Linq doesnt support this out of the box?

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Friday, September 19, 2008 1:54 PM by Alex

To say stored procedures hide the business functionality is a definitely defined as a comment coming from someone who really doesnt understand TSQL and wants to hide that fact. If all your business functionality is wrapped within your TSQL and your frontend correctly acts as a pure presentation layer then you will find that nothing is hidden - its all there -> In your stored procedures !

We have worked with 100% SProcs used in our systems for years. All our business logic sits ONLY on the DB side. If we have major business changes we find them easy to do by just modifying stored procedures. And no - nothing is hidden - its all there.

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Thursday, November 13, 2008 8:47 AM by Drew

Good article.  The database should act solely as a repository with no business logic incorporated within.  That doesn't imply the database shouldn't have constraints as the primary goal, without exception, is the protection of its data.

Goodbye and good riddance to Stored procs indeed.

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Friday, December 05, 2008 12:57 PM by Eddy

We only use stored procedures for data retrieval.  Also security is MUCH more reliable granting execute only to procs instead of each database table and view.  Looks like a step backwards of the intent is to NOT use procedures.  Especially since the link explaining the Execution Plan Caching and Reuse, this is true HOWEVER, if you have a bad plan to begin with, it will Still perform poorly, no matter if it is direct SQL call via LINQ OR a proc that is poorly written!  One other aspect lost is change management. If procs are used solely for data retrieve, update, delete, insert, there should be little to change in them as long as the schema design does not change... not good arguments to me.

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Monday, February 16, 2009 11:12 AM by Tom

Like so many other ORM promoters, you've gone with the argument that if you need to change your back end database you have to rewrite stuff and then you assume that your middle tier will never change, so the business logic will be safe there.

From 15 years of experience I can tell you that most corporate IT departments that I've worked with change their middle tier a lot more often than they change their database technology.

You also mention abstraction being one of "the key components to enterprise architecture". If that's the case, then why would you possibly want to couple your middle tier directly to tables rather than abstract them through stored procedures???

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Friday, September 04, 2009 2:31 PM by Luciano

Thanks this resolve a issue with the partner.

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Monday, November 16, 2009 8:48 PM by joedotnot

>We have worked with 100% SProcs used in our systems for years. All our business logic sits ONLY on the DB side.

Have you even heard of OOP and modelling your business rules with classes and objects? I am a fan of sprocs, but i restrict their usage for basic CRUD functionality, anything else is modelled in the middle tier.

# re: Goodbye Stored procedures, It’s the time to move on "Linq to Sql"

Thursday, November 19, 2009 12:13 PM by Jethro Tull

additional value is revealed when you have associated objects.. So when you save an object of type A you are persisting all related objects TypeA.TypeB.... Even more of a benefit is that you can have simple external transaction wrapping it up, so you never have the possibility of a stored procedure creating a record in table A but not in table B....

this discussion is the same as arguing for and against object oriented programming. The benefits are obvious: type-safe scalable and readable code.

Humans make mistakes, and by adding stored procedures you better know what you are doing cause you can easily reak havoc.

I myself am a big fan of nHibernate and Linq seems to offer the same advantages. And i loathe cursors and all the other bs that should be in easily extensible code rather than TSQL...

Leave a Comment

(required) 
(required) 
(optional)
(required)