SQL Server Performance Forum – Threads Archive

SS Best Practice

I am developing apps in ASP.NET using Visual Studio 2005 with SS as my data store. I have several tables and SPs defined. I call these SPs in my application for data retrieval and manipulation. These SPs in turn perform operation on tables such as SELECT, INSERT, UPDATE, DELETE, etc. Is this the recommended way to do things or do I need to add one more layer between my SPs and tables, the layer of viewes? My SPs then will only interact with views and views with tables. Is there a great advantage in doing this or am I OK in the way I am currently doing things?

As with all programming questions, it totally depends on the context, i.e., the size of the app, the number of users, the potential future of the application, the budget, and most importantly your client’s or boss’s timeline. From the sounds of it, if you simply have some apps with a few tables, and not many users on the system at once, then there is no reason to spend extra time developing business objects and data access layers. If, however, these are on going projects, with ANY potential for growth, or small apps with lost of concurrent users, investing the extra time, is the smart thing to do. Personally, even on the smallest projects I tend to create more classes and layers than required. On small projects this occasionally causes me to go over budget, but I’ve yet to run into a situation where six months or a year to a year down the road I was kicking myself for creating that extra levels of abstraction. My rule of thumb is you got the time, the extra layers, abstraction, and sticking to strict OOP programming standards will only help you. -Michael

Are you working with SQL Server 2005 or 2000? Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided â€œAS ISâ€ with no rights for the sake of knowledge sharing.

]]>