Hello,
given the following business and UI layer:
PersonInfo : ReadOnlyBase<PersonInfo>
PersonInfoList : ReadOnlyListBase<PersonInfoList, PersonInfo>
PersonEdit : BusinessBase<PersonEdit>
PeopleListViewModel : ViewModel<PersonInfoList>
PersonEditViewModel : ViewModel<PersonEdit>
PersonInfo is a small object only containing some header fields.
PersonEdit is the full featured object containing all properties.
and the following use case within a MVVM WPF application:
I do not want the complete list to be reloaded from the database, (or should I?).
Could this be done by instancing a new PersonInfo from the updated PersonEdit object,
and replacing the old PersonInfo from the PersonInfoList with the new PersonInfo?
Should I define a method void Refresh(PersonInfo newPersonInfo) on the PeopleListViewModel to do such an approach?
thanks in advance,
Alexander.
The challenge here is to implement a solution that doesn't cause a memory leak.
In concept, you can have some global reference to the PersonInfoList, and in the Saved event handler of the PersonEdit object you can just update the PersonInfo object with the new data. Or variations on that theme.
The trick is that it is really easy to end up with circular or static references that create a memory leak.
So the best solution is to use a UI framework that has a weak reference based event notification system (preferably publish/subscribe) so your Saved event handler on the PersonEdit object can publish a notification that a person has changed, and the PersonInfoList object can subscribe to that type of notification so it knows to update itself when the change has occurred.
Does any of that make sense.
In short, all you need to do is figure out a safe way to notify the PersonInfoList when a PersonEdit object has been saved. Preferably you'd pass a reference to the PersonEdit object as part of the notification.
The PersonInfoList object can then find the PersonInfo matching the PersonEdit object, and can tell that PersonInfo object to update itself based on the PersonEdit object.
The only additional thing to keep in mind is that you'll need to manually call OnPropertyChanged for each updated property in the PersonInfo object, because read-only objects don't automatically raise PropertyChanged events.
Hello Rocky,
just started work (6am) and found your fresh and detailed answer, thank you! 
I plan to use the Prism framework for the software.
What I've read about this so far, it provides a solution for notifications like you suggested.
One thing confuses me a bit.
You write to notify the PersonInfoList (model) about the saved PersonEdit object.
To do that, the business layer has to subscribe to the notification system, but am I wrong this belongs to the UI layer only?
Or do you mean the PeopleListViewModel gets informed by the notification and passes the update request to the PersonInfoList (model)
I like the idea to update the PersonInfo instead of replacing it with a new instance.
have a good night (just googled your timezone...),
Alex.
You can manage this entirely at the viewmodel level, and that's probably best, as it does keep any dependency on the event aggregator out of the business layer.
Copyright (c) Marimer LLC