cristobal baray
kids iPhone apps
s100+ pages

Last edited - March / 99
-- Hear and forget; see and remember; do and understand...

the model-view-controller (MVC) design pattern

introadvantagesexample appmodelscontrollersviewshererefs

MVC things to do...

Here's a list of some ways to extend this code in order to get more familiar with the way the MVC architecture works:

  • Create another view for the application. Have this one simulate an EKG, with a line scrolling across the window, and spikes occurring for each heartbeat.
  • Create a separate thread for updating the views (so that the model thread can continue unaffected by how many views need to be updated). This is useful in the cases where the model is computationally intensive or needs to be running on a strict timing pattern.
  • Implement a Command pattern [to be described in the GA writeup...but for now, check out Head First or Buschmann for info on it] to send the messages between the controller and the model. It will clarify the various actions that the model allows.
  • Implement the Visitor pattern [again, to be described in the GA writeup] to send multiple types of updates (multiple update objects) from the model to the views. Each view can handle each update type in its own manner. The Visitor pattern makes the code explicit about which updates are being handled and which are being ignored. [One could use instanceOf but that's not quite as pretty. Acceptable for small projects, it limits the "growability" of your application - use instanceOf with caution.]
  • Create proxies for the model, view and controller in order to facilitate distributing them among several machines. There should be two proxies inbetween each MVC pair:
    • the model to view connection becomes a model to view proxy which connects via a stream to a model proxy connected to a view
    • likewise, the controller to model connection becomes a controller to model proxy which connects via a stream to a controller proxy connected to a model
    • In both case, the proxies use streams to communicate - that way they can use pipes (same machine) or sockets (networked).
    • A couple of listeners might need to be set up to spawn off new proxies in the networked case.
  • In cases where the views receive their updates at varying speeds (a view is on a modem), then each view needs to be updated in their own thread. If not, the rest of the application (the model and other views that need to be updated) will have to wait for slower view to finish its update (the I/O blocks for all the modem acknowledgements). Create a multi-threaded distributed update, building up on the proxies and multi-threaded update methods mentioned above.

Of course, you could start by writing your own toy MVC application too. A good starter problem would be to write a model of a clock. Create two views that could display the time - one digital display and another view presenting the time on an analog display. A controller could allow the user to set the time and/or change between 12 and 24 hour displays. As you create it, I'm sure you can come up with more options to add - and you just might be surprised how easy it will be to implement them!

Naturally, you might want to look at some other docs on MVC in order to get a better grasp of it...and if you have comments on anything you've read here, drop me a note.

introadvantagesexample appmodelscontrollersviewshererefs