Modelling business objects with Encapsulated saving and retreival logic

As I mentioned in the last post that I will be discussing modelling of business objects ,
recently i had a chance to implement the idea that had been bobbing in my head for a
while.

Most of the previous projects that I have worked on had a seperate layer for business
data containers, and another layer for converting the business data container into sql
based information. In my opinion this is an unnesescary , it increases readibility and
maintainance issues.

classic business storage model

I wanted to encapsulate this logic of retrieving and saving the business data within the
business object itself. For e.g. I have a customer object name Customer, i could set all
the information in the customer object and call the save method... Customer.Save();

In the same tradition, i also made methods for retreive by id, retrieve by condition
methods as well, retrieve by id populates and returns an object of type customer,
whereas by condition returns a customer collection. (I didnt use the delete operations,
they wernt required in my case)

Encapsulating the save logic within the business object makes it easier to access and use
by developers. The Save logic consists of a single stored procedure that is used both for
updating and inserting new records. the logic to check wehther the current record is to be
inserted or updated if it already exists can easily be programmed in the stored procedure
itself.

Retriev by id simply constructs the object based on getting the record and populating the
business data by primary key

This type of modelling has other advantages as well, For e.g the Order object
encapsulates a cart object and cart items object, when Object.Save() is called, the
Cart.Save() is called which in turn calls the CartItem.Save() is called for each item in the
cart saving them one by one.

Another thing to keep in mind with a broader vision is that not all items are independant,
and you might want to implement transactions. If the items independantly implement their
own save methods this creates a problem.

Addressing this issue requires that all the classes that need to be saved in a transaction
should have a connection and a transaction members to assign them the connection and
the transaction object being used externally. A boolean transactionMode attribute or
property might be helpful as well

proposed business storage model

there are others who have explored this idea, here's a link to peter bells' blog
entryhttp://www.pbell.com/index.cfm/2006/10/20/Objects-or-Services--how-do-you-desi
gn-your-model

this is also the thinking behind CLSA.NET framework
http://en.wikipedia.org/wiki/Component-based_Scalable_Logical_Architecture

do post your comments on these thoughts