Prev: Subtle improvement to sequence diagrams....Re: Web based sequence diagram generator
Next: Separation of concerns
From: Bryan on 27 Mar 2007 21:26
I'm looking for a design pattern that will keep two in-memory objects
that are based on the same data in a DB in-sync with each other during
DB updates. I have a full featured 'Person' object with the typical
fields and methods, and a light weight 'smallPerson' object that only
contains ID, FirstName and LastName fields. I use the smallPerson
object for listboxes and such where I don't need to pull all the
person's info from the DB. I use the full featured Person object when
the user wants to edit all of a person's info.
Lets say I have a listbox showing a bunch of smallPerson objects and
the user clicks on one of the items to edit the person. A form pops
up which is bound to the full featured Person object. The user edits
this Person object's first name and then saves it to the DB. Now the
Person object is in sync with the DB, but the smallPerson object is
not. It will still show the old first name until I make another round
trip to the DB to refresh the objects data.
Any patterns to keep two objects based on the same data in sync?

From: Thomas Gagne on 27 Mar 2007 22:25
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.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
From: Kai Schwebke on 27 Mar 2007 23:10
Bryan schrieb:
> Any patterns to keep two objects based on the same data in sync?

A common pattern for this problem is "observer" (e.g.
http://en.wikipedia.org/wiki/Observer_pattern).

In your case however, aSmallPerson cannot
subscribe to a not (yet) existing Person object.
So lazy loading as suggested by Thomas may be a more
practical solution here.


Kai
From: Bryan on 28 Mar 2007 03:30
On Mar 27, 6:25 pm, Thomas Gagne <tga...(a)wide-open-west.com> 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.

From: Thomas Gagne on 28 Mar 2007 11:51
Bryan wrote:
> On Mar 27, 6:25 pm, Thomas Gagne <tga...(a)wide-open-west.com> 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.
 |  Next  |  Last
Pages: 1 2
Prev: Subtle improvement to sequence diagrams....Re: Web based sequence diagram generator
Next: Separation of concerns