Re: Design pattern to sync objects

On Mar 27, 6:25 pm, Thomas Gagne <tga...@xxxxxxxxxxxxxxxxxx> wrote:
Why can't they be the same object? If aPerson can also be a
aSmallPerson then it needs only be populated with aSmallPerson's data
until its necessary to fault-in the rest of the data. Because there's
only one object there's no need to worry about keeping them in-sync.

Lazy loading may well be the way to go. I wanted to encapsulate
different views and uses of the same data into different objects. For
example, the smallPerson object would only have read-only properties,
and would not contain any way to save the object back to the DB.
Lazy loading the full-featured Person object will work, though it will
also create some complexity. For example, lets say I lazy load a
Person object so that only ID, FirstName & LastName fields are
loaded. Then down the line I accidentally call the Person object's
Save() method. Since the object was lazy loaded, most of the fields
are "blank", and these blank field values will overwrite the
meaningful data in the DB. This can be avoided using some flags in
the object to let the Save() method know that it is not a "complete
object", but it is not the cleanest solution.
Perhaps I would like to create a different "View object" of a Person's
data that showed 3 different fields than smallPerson, or even n-
different "view objects". Now I would need to check some variable in
the Save() method to see what kind of data I have, and what should be
persisted to the DB.
Thus my want to abstract these "view objects" away from the base
class. Ideally the Person object would not know that there are other
objects exposing its data. The "view objects" would only know about
the Person object.

.