I’m conceptually trying to understand if I should be doing this:
item = Model()
screen = View()
brain = Controller(item, screen)
or this..
brain = Controller()
item = Model(brain)
screen = View(brain)
or this..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
or something else entirely?
To me, the first option makes sense. The job of the Controller is to co-ordinate between the view and the model. From that point of view, it makes sense for the controller to be the one that controls references to the view and model.
You can’t really have a controller without a Model and a View, however it makes a lot more sense to just have a View or just have a Model (for example, in unit testing). That’s why you want to pass in those dependencies into the Controller, and not the other two.
The Model and View are independent of each other.
Don’t think of the Controller as the brains of the MVC structure. Think of it as the dispatcher which handles the requests from the browser, and dispatches them to the Model. It then takes the data from the Model and packages it in a template friendly way, and then sends it to a View.
The Model is the brains in the MVC structure, and this is where you should put your business rules. Business rules are common across multiple controllers. So a document controller, and a reports controller may both use a User model to see who has access to those things. You wouldn’t want to repeat those rules in both controllers.
The View should use a HTML template to present the data in a non-datasource specific way. It should not be tightly bound to the schema of your database. To show the title of a document you would have the view output the contents of a template variable called document_title, and only the Controller knows how that variable was set, and only the Model knows why that document has that title.
2
MVC was originally defined to ease the programming of desktop applications. The view subscribed to model events, updating the presentation when the model changed. The controller merely translated user interface events (e.g. a button press) into calls to the model. So the controller and view depended on the model, but were independent of each other. The model was independent of both. This allowed multiple views and controllers to work on the same model.
The “MVC” architecture used for web 1.0 applications (full page refresh, no AJAX) is somewhat different. A web request is dispatched to a controller. The controller somehow modifies the model state, then sends one or more models to be rendered by a view. The controller and view both depend on the model, but the controller also depends on the view.
With web 2.0 applications, we are returning to the classic MVC architecture, on the client side. The model, view, and controller all reside on the client side as Javascript objects. The controller translates user events to model actions. The model actions may or may not result in an AJAX request to the server. Again, the view subscribes to model events and updates the presentation accordingly.
1
The view should subscribe to changes in the model. There is latitude in the richness of subscriptions as they may be detailed (show me inventory changes for this particular item) or generic (the model has changed); the view may query the model in response to change notification. The view presents its desired set of model elements on the screen, updating the screen as when handling change notifications.
The controller should push changes to the model, as a result of user direction (e.g. keyboard in put, mouse & menu commands).
The model maintain the model and a list of subscriptions, and should notify views of applicable changes via their subscriptions.
There also needs to be a mechanism to create new views and controllers (since in MVC you should be able to have two or more views of the same model (they could be the same view(point) or different view(point)s). Logically, we can consider that the controller needs to perform or have access to a view & controller (pair) factory, which can be part of the controller or another component.
7
MVC is more like a modularity pattern. Its purpose is that whenever you want to change the user interface layout (view), you don’t have to change de application logic (controller) or the internal data processings (model).
In order to acheive this, the pattern is to isolate the implementation logic of each MVC components. Still, it’s perfectly normal that there components know each others interfaces.
What I often saw is that the controler create or call model and view (thus it knows their interface) and model or view can notify the controler in return (more like a callback, or observer pattern). The important part is that the controler is not aware of layout structure.