Let's take the following example: We have a series of entertaining events on the television with each lasting only an hour and this goes on for 3 weeks. We want to create a simple App that displays the name of the next event.
We store the event in the above hierarchy where Weeks can store Days and Days can store Hours etc. in a collection (e.g., an
ObservableCollection), so it is not an is-a type of object hierarchy but a has-a type of hierarchy. We have, say, a
TextBlock on the UI that displays the name of the next event, so it is databound to the
Text property of the Event object deep in the hierarchy. Let's say, the name of the event suddenly changes and we have to reflect this on the UI.
In order to do this, I have to notify the UI that a different name has to be displayed. Whenever I face with a similar problem, I use changed events as in an
event fires in Event notifying Hours, then Hours also fires an
event notifying Days ... until I reach the highest layer that can directly notify the UI. This way, the
event broadcasted by Events is subscribed by Hours etc in Bottom-Up-kind of approach.
An alternative way is to make the UI itself subscribe to the ˙event˙s found in every Event found in every Hour etc. all the way up to the hierarchy, in a Top-Down-kind of approach.
Most of the time, this tinkering works, but what would be the accepted and proper way of notifying the UI in similar situations? Isn't there a more efficient way of doing this than doing all these subscriptions?
It was brought to my attention that the generally accepted way of dealing with event handling and data binding in WPF is in fact carried out using the MVVM pattern. So, I would like to narrow down my question to how such a nested object would notify the UI using this pattern.