I'm currently working on my first biggish project. It's a frontend facebook application that has, since last Tuesday, spanned some 6000-8000 LOC.

I say this because I'm using the MVC, an architecture I have never rigidly enforced in any of my hobby projects. I read part of the PureMVC book, but I didn't quite grasp the concept of the Mediator. Since I didn't understand and didn't see the need for it, my project has yet to use a single mediator.

Yesterday I went back to the design board because of some requirement changes and noticed that I could move all UI elements out of the View and into its own class. The View essentially only managed the lifetime of the UI and all events from the UI or Model.

Technically, the View has now become a 'Mediator' between the Model and UI. Therefore, I realized today, I could just move all my UI stuff back into the View and create a mediator class that handles all events from the view and model.

Is my understanding correct in thinking that I have devolved my View as it currently is (handling events from the Model and UI) into a Mediator and that the UI class is what should be the View?

  • I've only used MVC in web development so far so I'm no expert (MVC in web development is a little different) but it sounds like what you've created is a controller class who's responsibility is to determine which view to pass the current information to.
    – Kenneth
    Mar 10, 2012 at 13:08
  • Well, the structure is currently like so: I have internal view events (UIEvent) and external view events (ViewEvent). All UIEvents are handled by the View directly because they involve no business logic. All ViewEvents are passed to the controller, which goes on to make the model do its thing. I hope that helped.
    – IAE
    Mar 10, 2012 at 13:27
  • Your "mediator" class is really called a ViewModel. See also Model-View-ViewModel (MVVM). Mar 10, 2012 at 16:31
  • 1
    Does it really matter so much what you call it? Mar 10, 2012 at 19:12
  • 2
    Indirectly. If I knew what it was called, then I could perhaps differentiate it from similar concepts. I would also know where to look if I wanted more specific information on the thing I've created.
    – IAE
    Mar 10, 2012 at 19:32

2 Answers 2


The View should be the code for the UI and the Mediator should handle the events from the View. The Model should be separate from the View and have its "events" handled by a Proxy. Your Mediator can interact with your Proxy, but your Proxy or Model shouldn't interact with your view directly. See the PureMVC conceptual diagram for how things are supposed to interact within the framework.


In ASP.NET MVC, the view creates HTML code which send messages to controller. That is, a View may send a "modelled request" to a controller. The controller usually responds with a typed view, this type is a "ViewModel". This "ViewModel" is filled with data provided by the controller.

A typical MVVM is a web page (View) that has JavaScript that gets view information (JSON, XML, etc), or another new View, from a "ViewModel". Examples are: Gmail and Telerik Kendo UI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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