An object may fetch it's data from several tables. Also, an update of an object may update several tables and there may be some DB constraints. I think that using stored procedures can encapsulate such "DB-side logic" out of the business logic. I don't think an object should care how it is stored in the DB.josh wrote:Preferably. Each entity in your system should be an object, and all relevent knowledge about that object should be expressed directly in code in 1 place, its not about code quality as much as its about semantic unambiguity. You don't want to keep modifying data in different layers, its better to express that as domain knowledge directly on the object so it can be re-used in other parts of the system more easily.
Also, the usage of stored procedures increases the security.
EDIT:
Well, I think this topic is too big to be put in this thread
