Okay, I have been putting this off for some time, but I am jumping in with both feet. I recently posted a question on NJMSDeV message board regarding proper OO design. Needless to say, the response although credible is not necessarily what I was looking for.
Let's say we create a class called Customer. We make the class smart enough to hydrate itself via the constructor which is declared as "Friend". We have another class called CustomerRoot where communication to the Data Access Layer(DAL), the Customer Object and the outside world is all managed. It is basically your driver for your line of business. Public methods in CustomerRoot provide access from the outside world but only CustomerRoot can create a new instance of the Customer Object.
For this discussion, let's say the UI calls a public method in CustomerRoot to obtain Customer data. CustomerRoot will get the data from the database via the DAL. The DAL will return a DataSet. CustomerRoot then instantiates the object passing in the data. The object hydrates itself with the data and the object is returned to the UI by CustomerRoot.
So the question I had posed was this... Is it proper OO design to track if something has changed in the Customer object via a private variable (i.e. "Dirty as Boolean") within the object? Or should it be up to the outside world to know that the content of Customer has changed and call the "Insert", "Update", "Delete" routines of CustomerRoot to manage the changes?
If Customer is to handle it's own change routine, what should the mechanism for determining the kind of change that occurred look like? Instead of a flag (Dirty) should there be a field containing an Enumerated Type?
Public Enum ChangeType
None
Insert
Update
Delete
End Enum
Let's take this one level down. What if we create a CustomerCollection class? Now should there also be a (Dirty) flag in the collection class? This would surely prevent us from unnecessarily iterating through the collection to inspect each object checking it's Dirty flag. However, it is another layer of logic that must be coded in the object. How does the collection class learn that something has changed in the objects it contains? Do the objects fire an event?
The counter argument here and the answer I received from my original post is, use the DataSet object as it does most of what I am trying to do. So why do I resist this approach? Well as my friend Don pointed out, where do you put the business logic. Sure I can use the DataSet as a data container and have my object clean up the mess after the fact, but why? Isn't one of the most significant benefits of spinning your own objects the ability to control the data and implementation of proper business rules for such data? I prefer prevention over reaction to bad data.
Parting Questions:
Why isn't there a book or posts on the web that speaks about these kinds of issues? Where are the Enterprise development Gurus? Why are the examples in the VS Help geared mainly toward bound UI controls to data objects?
--chaz