I was hoping that someone could lend some ideas on how to properly setup a scenario I'm working with:
In my situation, I have a parent business object which uses another object as a property. As a simple example, consider this parent is a "Person" and the property is "FavoriteColor". In the user interface, the "FavoriteColor" property would be selected from a list of "Color" items, which are separately maintained & edited in a "Colors" collection.
Since the "Color" objects can be used by many "Person" objects, I understand the most appropriate way to set the "FavoriteColor" property on the "Person" is by storing the ID of the "Color" object and not a reference to the actual instance of the "Color" itself. In other words, a "using relationship" model.
However, by only storing the ID of the object, it seems that the "Person" will not be aware of any changes which occur to the properties of the "Color" object.
My question is: When applying the "using relationship" model and only the ID of the referenced "Color" object is stored, what is the best way to make sure the "Person" is aware of changes made to the assigned "Color" item?
My best guess is that this will require I set up a listener on the "Color" item when the ID is assigned to the "FavoriteColor" property.
Thanks for your help!
In what context would a color change while the person is also being changed? how would the change affect the person?
The color would be modified while the user is editing the person. Imagine a dialog window in which the details of the person are being edited. Within this dialog window, a button would open up a child window where the collection of colors can be edited, then the user would return back to the person after editing. As soon as the color is edited, the person would need to be notified of changes so it could execute any necessary business rules.
A "color" property is obviously too simple and perhaps a bad choice to describe the scenario.
In my actual case, the child property is a "material" (steel, etc) where the selected material will have properties such as cost, density, etc. If the cost of the "material" is changed, then the parent that references the "material" item will need to be notified so that the total cost of the parent can be updated (or total weight is updated if density is changed on the child).
Hi,
If my understanding is correct then you should revisit your object design.
In an "Edit" scenario where you can edit several objects you should rather have "owning" references rather than viewing it as "independent" objects with a "using" relationship. In an owning relationship you WILL automatically subscribe property changed in child objects (and get "Child-Changed" events).
So I would rather suggest to have material and the "editable" properties as child objects rather than independent objects and maybe "copy" the default values from a standard material list.
JohnnyBee - Thanks for the reply. I was planning a "using" relationship since the "colors" collection items could be used by many "person" objects. In other words, many parents could refer to a single child.
We handle this kind of thing.
When one is say - editing an organization record, we have a primary contact Id on that record and some associated read-only information for display - the contact's name, etc.
We have a pretty rich app where people can have multiple browser windows open with multiple records open (can switch between open records). When for example we'd have the primary contact and the organization both opened, we handle the idea that a saving of the primary contact can update the read-only information in the organization business object (that describes that contact).
We allow an interface to be defined on our business objects called IRecordChangeEventListener. The UI is responsible for knowing what records it has open. It is responsible for understanding when any given record it has open is saved/updated.
It then invokes a "ReflectRecordChanged" method through that interface on any of the open records that implement it. It includes the record type and the record Id. So the open organization would get this call and see, "hey, the contact matching my primary contact ID changed...I need to go back to the database to get some updated information" - this just leverages the same logic that would fire if my primary contact ID changed from 4 to 5 and I needed to get a new first & last name for example.
Such a record change notification system ends up working very nicely in our system. Whether it reflects "perfect design" or not, it allows objects to be told that other objects they are *using* were changed and to handle that information accordingly.
Just to add, we would never really store an editable Contact object as a child object of Organization. We would either store just the couple read-only properties containing first name, last name (things we need) as individual managed properties of an Organization or we would have a ContactInfo read-only object as a child object of Organization.
Copyright (c) Marimer LLC