Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Given that they generate the Create, Read, Update, and Delete (CRUD) functionality for you in most cases, does this imply that stored procedures won’t be used as often? If these methods use LINQ then that means no stored procedures are used, correct?
Any clarification is greatly appreciated.
Most ORMs (including LINQ-to-SQL and EF) will offer you the choice of either automated CRUD or stored procedures.
For example, while I’m happy to let the ORM deal with simple homogeneous CRUD issues (inserting simple records, etc), if I have a critical search method that spans complex data in non-trivial ways, I might choose to use a UDF (or SP) to ensure I can profile it, tune it, etc properly.
In some scenarios, there are security/audit issues that prevent direct CRUD, but in most cases involving an app-server, it is an artificial concern: if a hacker already breached your app-server, you already have major problems – and if they know the schema they can often use the SPs to do just as much damage.
If you are using the same backend from multiple applications on different technologies, then SPs are also useful.
Many of the original performance debates around SP vs text commands are now largely moot; a correctly parameterized text query can use the query-cache, and is injection safe, etc.