Maybe I should have elaborated a little more, Cetin.

What it means to only use Stored Procs to access the database, is that what you're striving for is to always have the same result set returned to your application. That way the application really doesn't need to change any bit of it's logic *AT ALL* when a different backend data store is used (other than to use a different base DataAccess class, which is simply a different version of your SQL DataAccess class with, say Oracle, commands instead of SQL commands ... compiled to a DLL with the same namespace and everything ... it's totally transparent to all the DataAccess classes that are sub-classed from it, because that base DataAccess class is using the IDB... interfaces).

Yes, the Stored Procs need to be written differently in Oracle than they do in SQL (I have no clue how different they might be, having never used Oracle) ... but the point is that they need to return the EXACT SAME result set.

Doing it like this means absolutely no logic changes in your application at all. Validation stuff that is handled in the app, is still handled in the app. No reason for it to be in the database.

I'd love to see a customer try to "duplicate" my app's functionality simply by using my Stored Procs!! Good luck with that!!

~~Bonnie




>>I think it's a mistake to not have Stored Procs. Look at it this way ... if you code all the SELECT, UPDATE, etc. commands in your DataAccess class, you've just locked into one flavor of SQL. Right in your app. You put it in Stored Procs instead, and you only have to worry about tweaking the procs, not your actual code. Your code shouldn't care one way or the other.
>
>Bonnie,
>I'm not against SPs but I don't agree that it's a mistake either:)
>If you do that with SPs you're coding it in Data Storage layer, if you do it in your application code then you're doing that in Data Access layer. In other words only changing the layer but still writing vendor specific code (maybe that is because I wasn't lucky to see vendor neutral code in that area ever). One way or the other someone have to write all that stuff. When it's in storage layer, most if not all, validation is done in storage layer. We do the validation in other layers too so validation is duplicated, no? Also if it's in storage layer, than customer really needs the db not my application. How do you handle such case? I have a solution myself but simply doesn't look good to me (marking each SP with a secret key that my application sends, if missing correct key still returns data but not the right one).
>Cetin