MVC Communicating form model to view

Troubleshooting General Help
1

I am trying to figure out the best way to communicate from a model to a view.  Each of my game objects has a view which contains all of the graphics code and a model which contains the logic


  • I have heard keeping a reference to the model object in the view is bad.


  • I tried using the observer pattern to communicate with the view. I sent custom message objects to the observers from the observable. This worked decently well although I had a ton of message objects.


  • Another possibility is for the controller to be the bridge which seems somewhat weird to me though.  Something like:



    Controller:

    LeftArrow.isPressed()

    {

    playerModel.moveLeft();

    playerView.setLocation(playerModel.getLocation());

    }



    What methods do you use and why are they good?
2
Grahf said:

- I have heard keeping a reference to the model object in the view is bad.

I would not say that. It's certainly bad to reference the view (or controller) from the model (at least in a structural/compile-time manner). But I'd say it's normal to make use of the model in the view and in the controller.
I'm going for the event-driven approach whenever possible. If you use parametrized method calls instead of event objects you're not creating any objects for the events. So using observers is fine.
Controllers should be kept simple. If possible one would want to alter only one thing - model or view.
3

Personally, I prefer the last method you mention: the controller/presenter contains all business logic, is the only one that "knows" about the other objects, and the model and view are completely independent of each other.  I like this because:

  1. The only thing the view does is present information to the user, and pass the user's interaction back to the controller.  Testing is very easy because there really is no logic to test.  If you trust your GUI library to reliably present what you want and pass back events, all the logic is contained in the presenter.  "Humble Dialog" is one term for this concept.
  2. The model is a data container only.  It doesn't worry about how to present that data or how it is otherwise used or manipulated.  "Separation of concerns".
  3. All logic is contained within the controller.  Automated testing of this class is now easier because you can pass it mock views and models that you can directly manipulate to test the controller's reaction to different events and data.



    Look at http://www.atomicobject.com/pages/Presenter+First for a more detailed explanation of this approach, and it's advantages.  I've used it on a few projects, and I've been quite happy with it.