Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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 '12 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 '12 at 13:27
    
Your "mediator" class is really called a ViewModel. See also Model-View-ViewModel (MVVM). –  Robert Harvey Mar 10 '12 at 16:31
1  
Does it really matter so much what you call it? –  Robert Harvey Mar 10 '12 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 '12 at 19:32

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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