Read a good article in Visual Studio Magazine titled Build SQL CLR Objects With .NET Very interesting read about using .Net languages to write stored procedures, functions, and triggers for SQL Server 2005. It is easy to see the benefit of leveraging the built in Framework API in store procedures. But this always makes me ask the questions, “Should I be writting complicated stored procedures?”
The goal of tiered design is to seperate code into layers traditionally presentation, business, and data. If I need .Net to write my store procedure, am I incorporating too much business logic in my data layer? Willie and I go back and for over each other's code asking, should this be in this layer or that layer? The bottom line question usually ends up being “Does it work?”
Here is the conundrum, most apps I write are not enterprise apps and will never service more than 100 users. But does that mean I should abandon good code practice? With tools like CodeSmith, if I can design a database, I can create three clean, well definied code layers with the click of a button.
I guess my point is features like .Net in SQL Server make it too easy for programmers to abandon good application architecture that is preached in every school and debated on every code related website.