2

In the MVC pattern, should model and view be very concrete and tailored to the represented component? Or should they be as generic as possible so that they can easily be reused?

Specific case

My data is a list of recorded frames. Each frame can consist of multiple data blobs, for example, an image and some meta data:

  • Approach (1): I could use a generic TableModel to represent the recorded data and a generic TableView to display it: Each column represents a frame and each row represents one kind of data. For example, one row is the image, one row is an image description entered by the user, etc.

  • Approach (2): I could create a specific RecorderModel, which maybe reuses the generic TableModel, and a specific RecorderView, which maybe reuses the generic TableView.

The latter seems to be preferable, because model and view can easily be udpated if specific changes are requested. However, it looks like I would end up with lots of empty classes like RecorderModel / RecorderView that just wrap the generic TableModel / TableView.

Are there pitfalls or important advantages/disadvantages I should be aware of? Is there a general consens like always use generic models, always use concrete views or something similar? Does it depend on the used MVC framework?

Community
  • 1
pschill
  • 1,807
  • 7
  • 13

2 Answers2

3

One of the key aspect of MVC is that the model is independent of the views. In fact the model can be represented by several views, and each change to the model data should be displayed in all the relevant views (typically using the observer pattern).

So if you start an MVC design by foreseeing a hard-wired mapping between specific model classes and specific view classes, you are certainly on the wrong path.

Try to imagine a more comprehensive example with two views: one that shows the table of individual frames, but another one that shows a color distribution graph of one specific selected frame.

So the model should not know any specific details of any given view. It should know only the relevant views to be notified of any data change. And it should of course know the interface to be used for the notification. This speaks strongly in favor of the generic approach for the view. By the way, MVC frameworks take in general care of this.

The problem is not symmetric: a view is allowed to query the model for displaying the information. In fact, it needs to know well the model. So the generic view has to be specialized, and the specialisation has to know the specific interface to query the model. If you'd manage to define a generic querying interface, you'd save yourself a lot of specific code when the model will later be extended. But this approach might require an additional overhead and complexity; using in the views the real specific interface of the model seems therefore a sound approach.

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • So you say I should use a generic approach for the view and the view should use the real specific interface of the model. But if the view uses the specific interface of the model, it isnt generic anymore, or is it? – pschill Aug 05 '18 at 10:54
  • @pschill Not necessarily: you can use a very generic interface for the view notification (observer pattern): your specific view matches the generic interface. But the implementation of the specific view may very well make precise knowledge of the specific model. There are plenty of ways to achieve that, because it's not the model that will construct the view. – Christophe Aug 05 '18 at 11:11
  • do you mean that we could implement MVC not by observer pattern, just by define interfaces of general view instead? That is, concrete model just hold the interfaces of view, without knowing concrete view. BTW, most MVC framework use observer pattern, not interface. Is observer pattern more attractive? – scottxiao Jun 30 '21 at 05:18
  • @scottxiao I used language neutral terminology in my answer and used “generic” withe the meaning used by the author of the question. With this in mind, it is not possible for a model to talk to views by just knowing an interface. What I meant is that the model talks to the views by using only methods of an interface implemented by all the views. It nevertheless needs to find the relevant views. You will therefore have some kind of variant of the observer pattern. But the interface can be richer than just notify() for a more effective communication. – Christophe Jun 30 '21 at 06:42
  • @scottxiao the term “interface” means here the API common to several different view classes. It can be explicit interfaces (Java, C#)(or protocols in swift), or the implicit interfaces defined by a base class or a template. – Christophe Jun 30 '21 at 06:49
  • @Christophe I ask a [question](https://stackoverflow.com/questions/68188696/why-couldnt-model-communicate-with-view-throuth-interface-in-mvc) about my confusion. I was intending to remove any `notify` interface , and implement all functions by interface, such as `onXXXDateChange()`； – scottxiao Jun 30 '21 at 07:35
0

There is a strong argument for a one to one mapping of View and ViewModel.

In an MVC app, usually the view will receive a ViewModel rather than the underlying business logic Model or Entities. Even if this ViewModel is a simple collection of Models with a few extra fields, say for pagination or a username. ie it might be more correctly called M-VM-VC although still different from MVVM

Once you have the abstraction layer of the ViewModel, these become throw away classes which simply arrange the data in a way which is helpful to the View.

If you need a slightly different View then it's easier and cleaner to make a new ViewModel class that supports any extra features that new View needs, that to make the Existing ViewModel generic enough to handle both cases.

However, it's only because the underlying Model is generic enough to be used in both ViewModels that this is possible.

Ewan
  • 70,664
  • 5
  • 76
  • 161