>The following is from Scott W. Ambler's white paper on mapping objects to relational databases. Scott W. Ambler is the author of The Object Primer, Building Object Applications That Work, Process Patterns and More Process Patterns.
>
>He has the following to say on using Stored Procedures for CRUD operations in an OOP application:
>

Interesting. It's amazing how many different viewpoints seem to use the same arguments to convince you that their way is best. In this case, the argument is coupling between a SP and the data. It seems to me, at some point, your code (in some layer) HAS to know something about the data. You can add additional layers to abstract the interface, but ultimately one of those layers will probably be tightly coupled to the data. It has to know something about the data in order to provide information to these other layers. It looks like it comes down to the developer deciding where changes are more likely to take place then using that information to formulate a data access strategy.

If I use SP's and make schema changes or change databases, I'll have to update the SP so my applications will continue to work. If I use a data layer to access my data, schema changes will probably require changes in the data layer. Honestly, both are requiring code changes so what's the difference?

I'd be interested in hearing other viewpoints - someone who has "been there, done that" would be most interesting. My knowledge on all this is mainly anecdotal. Educate me ;-)