Re: Design pattern to sync objects

Bryan wrote:
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.
So to avoid giving the object an isSmallPerson method you want to create
all the other complexity? I'm curious why you think save() will be
invoked accidentally since that would be a) a programming error and b)
should fail your unit and system tests.

Would a cleaner solution really require something more sophisticated? I
don't think creating a view object is more elegant than a simple
condition check inside save().

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
.