Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: Framework entity NHibernate , +
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.
Posted 2-Jun-11 19:42pm
Dr. Song Li158.2K
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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 Wink | ;)
  Permalink  
Comments
Dr. Song Li at 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 ...
Naerling at 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 ;)
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

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.
  Permalink  
Comments
Dr. Song Li at 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)

  Print Answers RSS
0 George Jonsson 215
1 Kornfeld Eliyahu Peter 169
2 OriginalGriff 120
3 PIEBALDconsult 110
4 BillWoodruff 85
0 OriginalGriff 6,165
1 DamithSL 4,658
2 Maciej Los 4,087
3 Kornfeld Eliyahu Peter 3,649
4 Sergey Alexandrovich Kryukov 3,294


Advertise | Privacy | Mobile
Web02 | 2.8.141220.1 | Last Updated 5 Jun 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100