Brady asks: > Why is this? ... If each SQL operation is well thought out, and coded > according to certain quality standards, there is very little different > to using stored procs.
I agree that the quality level can be fine. The problem is that you're storing the lowest-level persistence *INSIDE* the next layer up doubles (at least) maintenance tasks. When data model changes occur, you've got to change dependent SQL in every relevant module. So you go from potentially 0 assemblies needing to be changed, to MANY needing to be rebuilt and redeployed. Also, my organization is notoriously bad at tracking dependencies. It would be virtually impossible to track down all of the places where changes to be made. This is, of course, our own fault, but this is the world we work in... =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
