I personally avoid allowing any application to communicate directly with SQL Server unless it is a web application. Otherwise an employee can try to get direct access to your SQL Server by figuring out the connection string and/or doing packet sniffing. With the web services approach, the database server can be firewalled with no direct access from workstations. Yes, a web service adds a little bit of overhead, but it also adds (1) stronger security (2) a single place to fix query or business logic bugs [you can fix the web service as opposed to re-deploying the desktop app] (3) a reusable data service layer that can be consumed by multiple client types [desktop, mobile, web app server-side, JavaScript/AJAX, oData] (4) the ability to implement caching and performance enhancements at the web service level and (5) the option to implement redundancy via web farms.

For other readers’ sake, I did want to clarify that my article is about stored procs versus object relational mappers, not stored procs versus ad-hoc SQL strings. Plain-text (ad-hoc) SQL commands have the highest risk of SQL injection attacks. If I did not have a good ORM available to me, I would always choose stored procs over plain-text SQL commands. However, ORMs use parameterized SQL commands which are essentially “dynamic stored procedures” which offer the same SQL injection protection as stored procedures.

Honestly, a stored procedure can be more vulnerable to SQL injection than an ORM. Some stored procedures use dynamic SQL commands (exec @someSqlCommand), and this is very susceptible to SQL injection attacks. With an ORM, no plain text SQL commands are executed (string input is only passed via parameters, not appended to a SQL command). In short, there are lots of ways to prevent SQL injection, and an ORM is actually your ally in this effort, not a hindrance. Please read my response to Rob Kraft regarding database security.

I know stored procedures can be written as “dumb queries” (CRUD) without any business logic, but such CRUD-based stored procedures are unnecessary when you use a good ORM. In other words, business logic does not belong in the database, and if your stored procedures don’t have any business logic, then they are just doing simple CRUD that can be handled with an ORM, therefore those stored procedures reflect wasted effort and extra future maintenance. As for code re-use, this is done by separating your Business Logic Layer into a separate library that can be consumed by multiple projects (web app, desktop app, web service, etc).

By the way, good ORMs understand and take advantage of database relationships (foreign keys), primary keys, constraints and other data model attributes. They can enforce size limits on varchar/nvarchar data types so that users can be prompted about the issue instead of sending oversized input to the stored proc and throwing an error. Using an ORM does not throw away the benefits of an RDBMS; rather it supports and enforces the rules set forth by your RDBMS.

For web, desktop, web service and mobile applications, ORMs are usually the best technology choice. ORMs can replace 90%+ of the stored procedures written resulting in an application that is (1) more easily maintainable (2) less fragile in refactoring and (3) helps enforce clear separation of concerns of application layers. Business logic belongs in strongly typed managed code, not in brittle plain-text untyped T-SQL.

In response to your concerns:

• Developer Access – This is a whole other topic that I should write about. You don’t need to give everyone on your development team direct access to your live production database (or any shared database for that matter). A good development practice is for each developer to have their own local database instead of everyone connecting to one central database server. The local database would be cleansed of any sensitive data (SSNs, credit card #s) so it could be distributed to the development team. Developers should submit SQL change scripts via a source code repository. SQL change scripts should only be applied to a production (or staging) database server by a designated “build master” (generally the technical lead). Following this practice completely eliminates access by “untrusted developers.”
• Hacker Access – Most ORMs use parameterized queries which are essentially “dynamic stored procedures.” These have the same exact SQL injection protection that a stored procedure does.
• Abstraction – Abstraction really doesn’t belong in the Persisence Layer of an application. Your main abstractions (domain model) should be in the Business Layer.
• Code Generation – I know there are code generators that will develop stored procedures to handle CRUD for all of your tables. However, (1) this leaves an unorganized mess of stored procedures in the database [sure, there is a naming convention, but no way to organize into folders/groups] and (2) 100% of these CRUD stored procedures would be unnecessary with a good ORM. Stored procedure code generation leaves a mess of extra brittle code to maintain. The real tedium comes when your data model changes and you have to change all of those stored procedures. With managed code and a refactoring tool (ReSharper) this is fast and easy. With stored procedures, this is a big effort with higher chance of mistakes.

Why would you abandon all your system design principles as soon as you hit some arbitrary layer boundary? It’s like saying, “we’ll hit this web service and build a great system around it, but for the web service component we are going to just internally abandon those design principles we hold so dear and write it in procedural COBOL because we just feel like that’s easier”

What I didn’t get from the security part is that people like to set authorization on sprocs. If that’s the case, use views. Done.