CODEWITHSUNDEEP
model-view-controllerarchitectureviewencapsulationcontrollers
Brent Traut
Brent Traut

Reputation: 5794

How decoupled should controllers and views really be in MVC?

Views are, by definition, supposed to be logicless. When a user interacts with a view, it notifies its controller. When state changes in the app, the controller notifies the view. But I'm confused as to the nature of the communication between view and its controller when it's time to re-render some or all of the view.

Let's pretend I'm making a two player card game. The view is responsible for showing the deck, the discard pile, the cards in players' hands, and any other UI components. When a player plays a card, the view needs to reflect this change, and it's the controller's job to notify the view to do so. Which of these options is the best way to handle this event?

  1. The controller tells the view simply to re-draw. The view, through the controller, has access to all the parameters of the game state. It uses these parameters to re-draw everything including the deck, both player's hands, etc.

  2. The controller tells the view that a player played a card. The view knows that when a player plays a card, only that player's hand needs to be re-drawn. Like option 1, the view uses the parameters of the game state to determine how to re-draw the player's hand.

  3. (Similar but different from 2) The controller tells the view to re-draw that player's hand and passes it all the parameters needed to do so. The view has no access to game parameters.

  4. Any other approach I'm missing?

Option 1 seems to be the easiest two write because the view is stateless -- it just re-draws everything every time. But for that same reason, it is very wasteful. We don't need to draw both player's hands when just one player played a card. It's also difficult to do things like animation because every time we re-draw, we're essentially throwing away our old canvas and building a fresh one with all new view components.

On the other end of the spectrum, option 3 seems to be best in terms of removing logic from a view, but it comes with some issues. First, I've found it more difficult to write because it's imperative that all the proper messages are sent to the view. If any are missed, the view won't properly reflect the state of the app. Second, it seems like a full re-draw is still necessary at times for when, say, the user is restoring a saved game in progress.

In both options 1 and 2, the view "pulls" data about the game state whereas this data is "pushed" to it in option 3. Should views be able to request information like this, or does this imply that there's too much logic in the view?

Thanks in advance for any light you can shed on this topic!

Upvotes: 1

Views: 293

Answers (1)

jgauffin
jgauffin

Reputation: 101176

MVC is not the best fit for all applications. It also depends on what kind of frameworks which are available.

By not taking the platforms/frameworks into account I'll say that HMVC (Hierarchical model–view–controller) or PAC (Presentation–abstraction–control) is a better fit for you since a page can be splitted up into several parts (three views: hands & deck).

When it comes to native applications (GUI) it seems like MVP is preferred over MVC.

Martin Fowler has a nice article about the different GUI patterns here: http://www.martinfowler.com/eaaDev/uiArchs.html

Upvotes: 1

Related Questions