Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Do we really need to send Notifications to Mediator?  (Read 6457 times)
Vareyes
Newbie
*
Posts: 2


View Profile Email
« on: October 02, 2009, 06:46:47 »

Hello everyone, I have one simple question.

Both Command and Proxy have access to Facade, wich means, that they can retrieve any Mediator. If so, we can get a Mediator's instance, and then directly call one of it's functions instead of sending a Notification for e.g.:

var myMediator:MyMediator = facade.retrieveMediator( 'mediatorName' ) as MyMediator;
myMediator.update();

So my question is, why do we actually need these listNotificationInterests() and handleNotification(notification : INotification) functions within Mediator, and why do we send Notifications to Mediators?

Thanks :)

Marcin






Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 02, 2009, 07:05:49 »

Refer to the classic MVC diagram: http://puremvc.tv/#P100/T110

The Model should never concern itself with the View. EVER. It may notify the View, but not update it. This is a rule of MVC, not just PureMVC.

So a Proxy would never fetch a Mediator. Why? Consider always that your Model tier (i.e. Proxies, VOs, etc) will be reused elsewhere in another app with a different business focus.

For instance, I'm currently developing a little application that allows you to navigate through all the PureMVC stuff (code, presentations, docs, etc) in a Flex web interface. It reads XML files for navigation, which I am cranking out by hand at the moment, but I will eventually build an AIR app to maintain them. That app will have a different purpose altogether. Taking my form inputs and saving them as XML or visa versa. So if those Proxies were make dependencies on the View tier code for the visual roamer I'm building, it would be hard to extract them for use in  a pure data maintenance environment. Thus they do what they're told. The fetch data, and expose methods for working with it, but they do not care what the business of the actual client is. All MVC-based RIAs should be written with this scenario in mind because it's a very common one.

So Proxies send notifications because they don't  actually want to know any of the other actors in the app.

As for Commands retrieving Mediators, you can do this, and have the Mediator expose methods for the Command to use for manipulating / updating the View. However the actors are more loosely-coupled if you send a notification. The chief benefit of the publish/subscribe nature of notifications is this decoupling effect. You can swap out the Mediator that answers for a given notification without having to affect other code.

Also, if you have a Command that wants to do a  lot of puppeteering of the View Component (leading to an 'I wish this stupid mediator wasn't in the way' mentality) then you're probably dealing with code that should be encapsulated inside the View Component itself rather than deep within the application. This allows more reusable View Components because they don't rely on the app to carry out their behaviors for them.

-=Cliff>
Logged
Vareyes
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: October 04, 2009, 11:43:22 »

Thanks Cliff :)
this makes a lot of sense!
Logged
Pages: [1]
Print