MVC controller and decoupling explained

Question

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?

Answer 1

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.

Answer 2

Your MVC view should actually be bound to an interface not to a concrete model. This allows you to perform the decoupling by which the view can accept any IModel that adheres to its expectations. To put it into context using your code:

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

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

In several frameworks you may not have this kind of granular control over the definition of the view, but the principles don't really change. If all of your code is against an interface (re: contract), then the concrete implementation no longer matters so long as all objects adhere to the contracts. When dealing with framework objects the interfaces may not be available, and you may have to resort to using this same technique with the framework base classes instead.