MVC who knows about whom?

Question

In the Model-View-Controller pattern, I do understand the role of each component.

The Model represents our application's domain model. The View presents this information and the controller manipulates business logic.

I do not understand from any diagram that I saw, who knows about whom. Does the View know about the Controller? Does the Controller know about the View?

All I know is the Model should not know anything about the view, because those two should be independent. As for the opposite I'm not sure.

Answer 1

The Model represents our application's domain model. The View presents this information and the controller manipulates business logic.

Indeed, the view presents the user interface that presents this information. But the controller processes the input from the user. There's no business logic in an MVC controler: the business logic is packed together with the domain model.

The MVC litterature is full of variants and misunderstandings. A very close pattern is the Entity-Boundary-Control pattern. An EBC controller indeed provides for business logic. But not a traditional MVC controler.

I do not understand from any diagram that I saw, who knows about whom. Does the View know about the Controller? Does the Controller know about the View?

The controller knows them all: the controler receives user input, interprets it, and if requested, creates new views or sends commands to the model.

Each view knows very well the model since it can query the model to present the relevant information. But it doesn't have to know the controller.

The model knows a little about the views: the views can be observers of the model, and the model needs to notify them if there are changes.

All I know is the Model should not know anything about the view, because those two should be independent. As for the opposite I'm not sure.

The model shall indeed not depend on the view: many views can exist for a given model and the model should known nothing about their details. However, it shall know how to notify the view. So there is an interface dependency: the view shall implement the notification interface, whereas the model just needs to know the interface.

Answer 2

As an "old-hand programmer" (koff, koff ...), let me just try to clear the air here:

"MVC" is simply a framework (one of many, actually ...) meant to delineate "the one key idea that (IMHO...) is really important": separation of concerns.

The essential idea here, "literally, no matter how exactly you slice it," is that there are benefits to "slicing" an application architecture into distinct pieces which, by their position in that architecture, can focus on some concerns while essentially excluding others.

"MVC" uses this breakdown:

• View: Handles user input directly.

• Controller: Serves the view, tries to be more-generally aware.

• Model: Talks with the database, and abstracts away the peculiarities of it ("which are legion").

But, in fact, it is only one of possibly many separation of concerns, and in practice there's usually quite a lot of "cross-talk" between the layers. So, "don't get bent out of shape when you see it – you will, and it's okay."