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?

  • There's no such thing as complete decoupling. Without some knowledge of the model, there's no way for the view to display or update the model's fields. See also the ViewModel object, which decouples by provides a mapping between the View and the Model. – Robert Harvey Sep 16 '15 at 17:21
  • Also note that, in a properly "loosely-coupled" system, coupling normally just occurs one way. In MVC, the view must know about the model, but the model never knows anything (or cares about) about the view. – Robert Harvey Sep 16 '15 at 17:24
  • It's OK for View to know the Model. The GoF design is based on the assumption that Views are less stable than the Models over the time of a project. If you make a change in your Vews, you don't want the Model code to be affected. The best example of this is Microsoft Word. The user interface (Views) of a document have changed a lot over the years, but the file format (the underlying model of what is a document) has changed much less. – Fuhrmanator Sep 18 '15 at 13:27
  • I know I'm in a contrarian minority, but I have a problem with the idea that decoupling the M, V, and C are a good idea. (I suppose in some/many situations there is no good alternative.) My alternative is here, here, and here, and there is plenty of public code if you're interested. – Mike Dunlavey Jan 14 '16 at 19:42
  • @MikeDunlavey are you sure this has something to do with my problem? I even didn't understand what it was about? Could you explain in 2 words what is your invention. – Narek Jan 15 '16 at 4:27

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.

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.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.