MVC controller and decoupling explained

design-patternsmvc

In this article you can see that View has (uses or aggregates ) controller and ConcreteView has Concrete model. 

public abstract class View 
{ 
    public abstract void Update(); 
    private readonly Controller Controller; 
    protected View() 
    { 
    } 
    protected View(Controller controller) 
    { 
        Controller = controller; 
    } 
    public void ContextInterface() 
    { 
        Controller.AlgorithmInterface(); 
    } 
} 

public class ConcreteView : View 
{ 
    private object ViewState; 
    private ConcreteModel Model { get; set; } 
    public ConcreteView(ConcreteModel model) 
    { 
        Model = model; 
    } 
    public override void Update() 
    { 
        ViewState = Model.ModelState; 
    } 
}

So this is considered classic MVC by GoF. I don't see where how view is not aware of the model and vice versa. I mean, what if we just put model pointer in the view as it is now and we don't use controller. What is the problem here? What that Strategy pattern does for me (see in the article). Plus as much as I know, in MVC the view should not know about the model and model about the view. So if you have a reference in the view on the model, doesn't it mean they know about each other?

Best Answer

The View needs the Model in order to update its view of the model (Model here could be an abstraction or a concretion). The Model knows that there may be abstract Views that are interested in updates, but the Model does not know the concrete type of View(s).

The Controller changes the model. If there's an element of the View that enables modification, then the View will need a Controller. Otherwise, the View would not need a Controller.

Related Topic