Click here to Skip to main content
15,799,257 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
I searched over .... I see many advantages, but it seems that all the advantages comes from a comparison over in-line SQL. I know in-line SQL is bad. But why compare with a bad one to show the other better?

If stored procedures are used (possibly exclusively), it seems none of the advantages still exists. Stored procedures definitely provide performance advantages in terms of security, performance (If a ORM can outrun a stored procedure, then the stored procedure is badly written) and a well written stored procedure is an automatic repository (pattern). Stored procedures can definitely provide better transaction and transaction isolation control.

I really appreciate an answer -- how ORM is better over a "WELL" architected application using stored procedures. We should compare the best against the best, not comparing a well designed application using ORM against a poorly designed application without ORM.

I have been using the Entity Framework for a while now. A few advantages for me are automatic Class creation from the DB metadata and using LINQ. Also, using an ORM tool does not mean you cannot use Stored Procedures. I do not think one method is better than the other. It depends on requirements (an ORM is definetly faster for development), what you know (if you don't know EF, but have to ship next month go with what you know), if you know EF and have to ship asap I recommend using it.
You also have to ask yourself if you want to do a SELECT query through a Stored Procedure rather than an ORM (LINQ) because it is 0,00001 millisecond faster. But as I said, Stored Procedures can be used using Entity Framework very easy.

So while I personally prefer EF because of its fast and easy to use Class creation I am not saying it is better per se (it has some drawbacks as well! Sometimes it does not map correctly, or an error occurs which results in you losing all your auto-generated classes. Then again, when the error is fixed the Classes are automatically recreated again). The internet is full of to-ORM-or-not-to-ORM discussions. I suggest you start clicking some links here[^] too ;)
Share this answer
Dr. Song Li 5-Jun-11 18:55pm    
Thanks ... Just a quick question. When you state the advantages, are you comparing with data accesses using in-line SQL (or mostly use in-line SQL, and when ORM causing some issues, use stored procedure as a substitute)?

I am trying to get a comparison between ORM solution and the 100% stored procedure solution. Any comments? Well, I personally favor the 100% stored procedure solution, because it does provide better security, faster speed (in certain cases, the level of speed difference can be significent!), easier transaction and isolation level control. Most importantly, you are controlling the SQL commands issued to the database engine. You can take advantage of any possible features that the database engine provides to you. Because you are commanding what the database engine what/how/when to do, you have better confidence on the behavior on your code, which results into few bugs and less burden of testing (including unit testing).

But I definitely do not want to be so self judged. I really want to get a convincing reason to use ORMs, so I do not miss any good things come with them.

Any comments? Thanks ...
Sander Rossel 6-Jun-11 2:33am    
Well, perhaps I am not the best person to comment on that. My company only recently started to 'do things right' with EF. We do still have a DB where almost everything is in the dbo schema. Finding a Stored Procedure there alone can be so tiresome that LINQ was a great relief. And that is not even the 100% Stored Procedure approach... The Stored Procedures that we do have rarely handle stuff like security. I do agree that it is faster though.
I am currently using LINQ for almost all my data fetching. For stuff that cannot be done with LINQ (or which you do not want to do with LINQ) I use Stored Procedures instead.
Another reason for me to use LINQ instead of SQL Stored Procedures is that (for me) VB code is easier to debug than Stored Procedures in the DB. And I can directly see where certain SP's are used by finding all references (EF handles SP's as if they are Methods). On top of that I am more comfortable with writing VB code than SQL code.

If you really want to make a good decision about it I would suggest grabbing a DB such as Northwind, creating a new project, and get that profiler running. Fetch some data the way you think is best and compare it to EF's queries. I must say that when I look at SQL profiler it seems EF sometimes generates a lot of overhead. But I only mind when performance is visibly affected ;)
One advantage is that you learn how to not expect a 3rd-party library to be a magic bullet, and that no matter what you select, there will be issues to overcome.
Share this answer
Dr. Song Li 5-Jun-11 18:58pm    
Hopefully, ORMs do not only give me issues, but some advantages that makes me want to use them. I am struggling ...

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900