I can't agree more.

Several years ago it used to be considered good, albeit abstract, best-practices architecture to insulate client software from raw CRUD access to data. It's now critical to wirefall db ops in a distributed world and I see it more and more.

The .Net architecture almost screams for it as well.

>I'm gonna put this in my blog....basically, in no order of importance:
>
>- They provide an application/client-agnostic API for accessing the database.
>
>- Having an application-agnostic API for the database can really become beneficial in a corporate environment with several applications and developer teams.
>
>- If I had a dime for every time an I.T. manager breathed a sigh of relief when I told him/her that something could be added/changed/fixed simply by tweaking a stored proc (as opposed to having to update an application DLL), I'd have plenty of dimes.
>
>- I can abstract out and establish an API and build stored procs independantly of the application, and in many instances can make changes without disrupting the development environment
>
>- The new tools for building custom database unit tests in Visual Studio Team Edition for Database Professionals are outstanding. (If anyone is interested in building unit tests for stored procs, you HAVE to look at this product. It is fantastic).
>
>- It's much more difficult for a DBA to manage database code if it's residing inside application logic
>
>- SQL 2005 contains many new language features that are best utilized inside stored procs.
>
>
>As I've said before, I use them as a strong starting point, unless there are good reasons for not doing so. In general, I believe that all external access to a database should occur through stored procs.
>
>Clients WANT me to use stored procs. I work with at least a few new I.T. teams each year, and I can't think of one that didn't want to use them. And when the ultimate decision is left to me, I use them on a regular basis.