Design: How to inform controllers about data modification across application

Question

In a big system mvc-based there are views responsible for editing data and views that display that data.

Example: UserManagementView and UserSelectionView.

Each subsystem should know whether it needs a data update, after another subsystem has made changes to the same data, in order for its controller to know whether a data update is needed.

My thoughts on this is something like the observer pattern (which is kinda integrated in c#) and all controllers would be listeners and eventually would get notified that data-manipulation occurred.

BindingList<> for example provides a ListChanged event. Similarly, an interface can be created for each data-structure and notify the controller about the change. This would add overhead (IMO) and I find this solution difficult to maintain in a big system, also updating data anyways is not a solution.

Which architectural design can help in this kind of scenarios?

Answer 1

This question sounds like you are trying to use MVC without the model part. If I've misunderstood, editing your question to include a practical use case (example) may help us understand the context.

In general though, nothing should really be persisted/stored in your controllers. So there should be nothing in the controller that requires 'updating' or 'notifying' (ie: no data). Rather the data should be in a separate 'model' layer which manages all your data. Then the views read from the model layer to grab any data for that view.

For a quick refresher check out the wikipedia page on MVC which has a nice classic MVC flowchart and simple write-up on component interactions.

Example for Discussion

Let's try to contrive an example for the purpose of understanding this problem.

Let's say I have a list of users in my application. This list might be shown on:

• A master admin list view
• An admin edit user view
• A user's personal profile view
• Maybe more?

Each of those views will request the data from your model layer and show something on the screen.

Now let's say a change was committed to one user's profile. That would be accomplished via a controller method which does any work necessary to apply some changes to the model.

My understanding is that you want all of those views to update to reflect that change. That means the views need to reload data from the model. It should not be getting this data from the controller itself, even if the controller triggers this reload/refresh - or rather a controller method may facilitate querying from your model layer. The important part is that you aren't maintaining multiple copies of your data in multiple controllers throughout your application. The persistence is centralized in the model layer.

In the case of winforms the model layer may be able to provide something like the mentioned INotifyPropertyChanged interface if your UI components are built to recognize that interface and refresh accordingly. But that is a fairly platform dependent approach.

A more platform/context agnostic approach would be the pub-sub (publish-subscribe) pattern also mentioned already. In this case each controller method that makes a change to the model would also publish a notification of its changes. Any views for that data can be listening and respond to such a notification by refreshing/reloading the view's data from the model layer.