Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?
share|improve this question
add comment

3 Answers

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.

share|improve this answer
    
+1 - although I'd stress that in MVC the View CAN observe but CANNOT mutate the Model. –  sunwukung May 17 '11 at 11:16
add comment

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:

http://blogs.infragistics.com/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx

Hope it helps.

share|improve this answer
add comment
> What's your preferred way of dealing with this?

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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