tags:

views:

53

answers:

2

Hello. I've had mostly experience with "server-side" mvc frameworks very popular in different languages like ASP.NET MVC or Zend Framework for php, Spring for Java etc.

Some of them are also possible to use for desktop applications development but I never tried that.

I fully understand that design patterns should not limit implementation, they should generally provide ideas and common rules that can be differently implemented.

Now I'm playing with one of those mvc frameworks for usual Desktop Applications development (it does not have many tutorials or a decent quickstart) and I have some questions regarding to the mvc paradigm. Here is one of them:

What are common ways to link different views / controllers? If I click a button, special controller for that button dispatches the event that is generated, does something with the model, changes view state. But what if I need to interact with another view? Like, when I click on a button, it changes a model, but also I need to open another window or change state of another window (hiding a button on another window let's say...), without changing actually the model. What are common ways here to address this? Should my first controller generate an event for the second controller (or second view)? Or should the second controller be handling events from first view?

Some links or examples for any languages/frameworks would be really helpful, thanks!

+1  A: 

The common pattern for loosely coupled communication between objects is the Mediator pattern:

http://en.wikipedia.org/wiki/Mediator_pattern

This allows communication between objects through a mediator e.g. one object publishes a message to a mediator, and zero or more objects may subscribe\receive the message. The pub\sub is carried out through the mediator, not directly, so no direct coupling.

An example of this pattern is the "event aggregator service" in CAL (aka Prism), a composite application framework for WPF applications, typically used with an MVC-like pattern - MVVM:

http://msdn.microsoft.com/en-us/library/ff648465.aspx

http://msdn.microsoft.com/en-us/library/ff647600.aspx

Update

In MVVM, the event aggregator service (mediator) is typically used to allow loosely coupled communication between viewmodles (somewhat like controllers in MVC). In this way viewmodels can publish and subscribe to interesting general messages.

chibacity
That's not what I was asking for. There are many ways and patterns to establish connections between objects in an app, but I'm rather asking "what should be connected with what and how typically".Mediator like all the other 'Star objects' (registry, service locator, globals etc) is also not the best way to do this kind of things.Make sure you've taken a look at Dependency Injection and Inversion of Control. And thanks anyway.
lcf
Ouch - I'm very familiar with dependency injection and inversion of control thank you very much. Only trying to answer your question dude. Perhaps you should make your question a bit clearer... You mention in your question that you are very familiar with MVC, so surely you know how to hook that triad up. I am merely saying that the mediator pattern is common for communicating between views, for instance... Using raw events would introduce coupling.
chibacity
Oh, sorry, probably didn't get you clearly. And I'm really appreciated you found time to answer. Is it correct that you would solve my kind of problem via linking views? (via raw events or mediator pattern doesn't matter yet for me, I should understand the idea first).Like if I click a button in a view and it should hide a label in another view - would the first view generate an event that would be handled by the seconds. Right? Without the controllers participation. Or I'm still missing your idea?
lcf
After thinking a while I think now that your proposal is probably a good option, I will consider using something like that. sorry again for being rude (may be) in my first comment.
lcf
Vote me up then dude! :)
chibacity
+1  A: 

Interesting question. My thoughts:

You're dealing with a fundamental difference between server-side and desktop: a Windows application can present more than one View at a time. (We'll ignore partial views and other hair-splitting for the moment.)

In MVC, the Controller is the where the Action happens (pun intended) so that's where things should be linked. You want a loosely-coupled solution, which calls for Dependency Injection. Think Spring, Unity, MEF, etc. This allows you to wire the Controllers together so that they can respond to events in each other without violating any principles (i.e. Separation of Concerns, Single Responsibility.)

Dave Swersky
That's something already. I think though that the actual difference between server-side and desktop is no one View at a time. The difference is that in server-side case we always handle one particular event at a time (actual HTTP request) which may be dispatched by several controllers. Should it be somehow similar in the desktop case? Got an example? I'm also aware of course of the DI and principles you mentioned. That's exactly what I'm looking for for my particular case in more details. Do you propose one controller to be linked to another one? And then...?
lcf
Without knowing exactly which "mvc frameworks for usual Desktop Applications" you're playing with, it's difficult to be more specific. The idea is that the Controller contains the logic that responds to actions in the View, so if you want a View to affect other Views, link them by loosely coupling the Controllers.
Dave Swersky
Any framework's approach would help.
lcf