1

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?

2

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.

  • 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 5 '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 5 '18 at 11:11
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.

  • 1
    wait, why are you talking about ViewModels when the question seems to be about plain MVC, not MVVM? That's a completely different architecture. – amon Aug 1 '18 at 10:15
  • Because MVC in practice is often M-VM-VC as i explain in my second paragraph – Ewan Aug 1 '18 at 10:17
  • @Ewan could be MVP as well, then... – Christophe Aug 1 '18 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.