I have the following situation. Imagine you have a MainWindow object who is layouting two different widgets, ListWidget and DisplayWidget. ListWidget is populated with data from the disk. DisplayWidget shows the details of the selection the user performs in the ListWidget.

I am planning to do the following: in MainWindow I have the following objects:

  • ListWidget
  • ListView
  • ListModel
  • ListController

ListView is initialized passing the ListWidget. ListViewController is initialized passing the View and the Model.

Same happens for the DisplayWidget:

  • DisplayWidget
  • DisplayView
  • DisplayModel
  • DisplayController

I initialize the DisplayView with the widget, and initialize the Model with the ListController. I do this because the DisplayModel wraps the ListController to get the information about the current selection, and the data to be displayed in the DisplayView.

I am very rusty with MVC, being out of UI programming since a while. Is this the expected interaction layout for having different MVC triplets communicate ? In other words, MVC focus on the interaction of three objects. How do you put this interaction as a whole into a larger context of communication with other similar entities, MVC or not ?


I will start by providing you with great resources for MVC design. The first is the WWDC 2010 Session 116 Model-View-Controller for iPhone OS (really just iOS), it is slightly tailored to the iOS classes, but gives a lot of generally useful information too. You have to register to be an Apple developer (free) to get access to it. The second is the publicly available Stanford iOS course, again it will be tailored to iOS, but his introduction class focused on MVC in the general sense.

Ok, so what you get from those resources are rules such as Views don't own the data they display.

Straight from the Stanford course:

Model: What your application is (but not how it's displayed)
Controller: How your model is presented to the user (UI Logic)
View: Your controller's minions


Controllers: direct communication to models and views.
Views: "blind" communication to controllers (target-actions and delegation). No communication to models.
Models: broadcast communication to controllers (Notification and KVO). No communication to views.


For your specific case, I'm not sure I understand what you're describing 100%, I'm not sure what those "widgets" are (at least for Android, a widget is a bundle of MVC(s) that provide some functionality like a search bar widget). But if you mean that the ListModel is something like a title and implicit index, and the DisplayModel is a matching description for the given index, then I might have a MainController (for the main view that is containing these two subviews or fragments). The user selects an item in the ListView triggering some sort of onSelection function on the MainController (now the MainController knows what item they selected). The MainController passes that along to the DisplayController (now the DisplayController knows what item they selected). Finally, the DisplayController can use the DisplayModel to find what needs to be displayed now and then tell the DisplayView to display it.

Alternatively the DisplayController can respond to the onSelection function triggered by the selection in the ListController directly, but that connects components that probably shouldn't be connected. Because you said they were their own Views that means it could be possible to have a set up (possibly for smaller screens) that had the ListView on the full screen, a selection is made, then the DisplayView takes over the screen showing the description of the selection made. For that reason I would leave the views separate.


So, let's start by saying MVC is just a guide to producing nicely structured code, as far as I know it isn't strictly enforced. Next, for the "non-canonical" refer to what each component is suppose to do.

Essentially everything that isn't written to display something or interact with the display is part of a model. Models are the algorithms that perform tasks. Views are only to surface a UI, and provide ways for the program to interact with the UI (as in the target-action connections and delegation). This leaves the Controllers to be the delegates and targets for the Views. Think of the as kind of the gears under the views I guess. They should be the link between actions on the screen and functions and data in the Model. They should make sure the Views display the content you want to be displaying.

Here are pictures taken from the Stanford course (the first class) that show how and how not to set up multiple MVCs. (unfortunately I can post a maximum of 2 hyperlinks and no images)

MVC done correctly

MVC done incorrectly

  • The point is that I don't understand how the communication network is setup and organized. I understand the general idea of MVC, but it just shows how one view connects to one model through one controller. It says nothing about how multiple MVCs (potentially involving distant views, e.g. one button and a list not directly accessible to the MVC involving the button) interact. Additionally, it says nothing about who is in charge for tasks that are not "canonical". Who should submit a process to a queue, or create new entities in response to an event, entities that then become new model data? – Stefano Borini Feb 18 '12 at 22:49
  • Who is in charge of managing the Command queue for undo/redo ? All these questions on application design are left unanswered in the plain MVC description that is presented on textbooks. – Stefano Borini Feb 18 '12 at 22:50
  • Actually, the Stanford course does have a class on multiple MVCs as well. Also the rules of single MVC just extend, as in the only difference is that it is acceptable to have a model talk to another model (view's don't really talk to each other) and of course controllers can talk to each other. – Dandre Allison Feb 19 '12 at 18:35

HMVC might be what you are looking for. It's specially good when it comes to widgetry since it encourages decomposition on the client's side (i.e. view).

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.