I have recently started a new position, where the main project is written mostly in FoxPro. There is some (increasing) effort going on to move it to .NET. As the project is still in the early stages, very few pieces of the overall product are currently in .NET. Within these pieces, there are many places where SQL code is being written directly into the application.
My personal view is that ALL SQL code should be done in stored procedures, but I have trouble faulting the designers' positions and arguing my own because:
- Every single bit of SQL code that resides in the application is parameterized.
- N-tier architecture has been used, so all SQL calls, whether it be to stored procedures or SQL code directly in the application, is separated from the UI and the business logic.
- Much of the SQL code are simple select statements.
So, what I would like to know is if there are any best practices out there that specify how SQL code should be organized, and whether it is good practice, bad practice, or simply personal preference to have it in the application.