Admittedly my experience of using the MVC pattern is limited. It might be argued that I don't really separate the V from the C, though I keep the M separate from the VC to the extent I can manage.

I'm considering the scenario in which the application's model includes a number of elements that have a common base class. For example, enemy characters in a video game, or shape types in a vector graphics app. The view wants to render these elements. Of course, the different subclasses call for different rendering.

The problem is that the elements are part of the model. Rendering them is conceptually part of the view. But how they are to be rendered depends on parameters of both:

  • Attributes and state of the element are parameters of the model
  • User settings are parameters of the view - and to support multiple platforms and/or view modes, different views may be used

What's your preferred way of dealing with this?

  • Put the rendering code in the model classes, passing in any view parameters?
  • Put the rendering code in the view, using a switch or similar to select the right rendering for the model element type?
  • Have some intermediate classes as a model-view interface, of which the model will create objects on demand and the view will then render them?
  • Something else?

The View Helper pattern is defined in the (web-oriented) J2EE Pattern Catalogue, but is applicable in broader software architecture:

A view contains formatting code, delegating its processing responsibilities to its helper classes...Helpers also store the view's intermediate data model and serve as business data adapters.

In your example "formatting code" would be the element-specific rendering code.

A helper is responsible for helping a view or controller complete its processing. Thus, helpers have numerous responsibilities, including gathering data required by the view and storing this intermediate model

In simple terms, they act as an intermediary between MVC layers to solve a specific "problem" of scope (i.e. the view cannot contact the model).

Using helpers results in a cleaner separation of the view from the business processing in an application

Separating formatting logic from application business logic reduces dependencies that individuals fulfilling different roles might have on the same resources

With that in mind, back to your example. An element object's dependencies (for example, the specific view helpers) should be injected into it. The object doesn't need to know which helper has been injected as the helpers conform to an interface.

When the enemy object is rendered by the View its View Helper is invoked, which brokers the data between the Model and the View and completes any auxiliary processing. The View is then ultimately responsible for defining the visual output.

  • +1 - although I'd stress that in MVC the View CAN observe but CANNOT mutate the Model.
    – sunwukung
    May 17 '11 at 11:16

What you mean is that, your app. have several "enemies" that share some logic, and other logic and display is different.

There is a plain "Model View" pattern or plain "Model Presenter" pattern, where the view and presenter are used as a single entity. I couldn't find the link.

I have seen many frameworks, that allows you to use the M.V.C. as one model, several view, several controllers; but in real life, the programmer actually use one model, one view per one controller.

For example, the Windows File Manager (Konqueror, KDE-Linux guys?) uses a single Model (The filesystem), two controllers (folder frame and file frame).

The Folder frame, is the same controller, and has only one view. The File frame, is the same controller, but sometimes uses "list view", or "icon view" or "mosaic view"

Maybe, this patterns may help you:


Hope it helps.

> What's your preferred way of dealing with this?

Have one subview for each model element type that know how to display this type

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.