I am migrating an existing .NET 2.0, SQL Server codebase to a .NET 4.0, SQL Server 2008 environment.
The design pattern is that all app calls to the database go through a stored procedure. So there’s a get[object name] stored procedure that needs to be created or altered for most select statements.
So the disadvantages of this architecture to me are already evident: inconvenience.
What are the advantages of this highly enforced stored procedure design? (now in .NET 4.0 as opposed to using an ORM).
Actually – contrary to popular belief – performance isn’t one of the advantages of stored procedures – not anymore. Properly written “inline” SQL queries with parameters are just as fast, get “compiled” once by SQL Server (before first use) and remain in the procedure cache of SQL Server just as long as any stored procedure.
But stored procedures do have advantages – two main ones I’d like to mention:
the shield the user from the underlying tables. Which also means: it’s another layer in your security system. Your database users do not need access to the tables – and thus they won’t be able to cause any grief on those tables, either – by accessing them via Excel or Access or some other tool. This alone can be a huge benefit.
the second point is having a layer of stored procedure can give your DBA a place to optimize. You as a developer only call stored procedures – and the DBA can tweak them, fine tune them, make them run faster. As long as the parameter list and the return result set remain the same – you as a frontend developer won’t even notice (at least not in a negative way!)