Listening to Notifications on Mediators or going through commands

[Helmut Granda]

I have a small dilemma, so far through the documentation we can see how Mediators are able to listen to notifications which is really easy to implement. But I have found that using Commands for all my calls makes me feel more comfortable in that I dont have to tie my mediators to certain Proxies when there are changes to them but rather Commands are tied up to Proxy and Mediator Notifications.

This feels more natural forcing me to create my Mediators/Views/Proxies more open and not having references (or importing) from each other but they just expose their APIs which the controls are able to use as needed.

What is the general consensus in regards to this approach? I remember reading/listening something about Cairngorm using this method so in general I found the following

Allowing Mediators to listen for events
- faster development
- have to add references to other actors within the class
- less commands

Go through the Commands:

- slightly development
- lots of commands
- loose coupling ( not having to import classes to mediators/proxies)

[uncleunvoid]

i have the same decision to make.

coupling mediators and proxies closer together essentially makes the code less flexible and scalable, therefore I think I go with the idea of going through commands. there must be ways to make this more effective. E.g. there will be only a few properties needed to differ between all types of mediators that rely on XML data of sorts. one command can then cover all that middle-management.

[puremvc]

I have found that using Commands for all my calls makes me feel more comfortable in that I dont have to tie my mediators to certain Proxies when there are changes to them but rather Commands are tied up to Proxy and Mediator Notifications.

This feels more natural forcing me to create my Mediators/Views/Proxies more open and not having references (or importing) from each other but they just expose their APIs which the controls are able to use as needed.

Conceptually, there is nothing wrong with putting all of your application's Model tier interaction into Commands if it 'feels more natural' to you, except that it uses up way more cycles than necessary to get things done.

The Mediator is a long-lived actor, and therefore may establish a collaborative relationship with the Proxies (also long-lived actors) by declaring interest in their notifications and retrieving a local reference to those Proxies at onRegister time. This allows it to respond directly to Proxy notifications and to invoke methods directly on Proxy collaborators without having to retrieve them each time.

A Command, however requires notification from the Mediator (the first additional step), instantiation (second additional step), retrieval of Proxies (third additional step). Since a Command is instantiated only when needed and discarded thereafter, these extra steps must happen every time.

If you consult a diagram of the original MVC meta-pattern¹, you see that the View and Controller are equally permitted to update the Model. They have direct associations. The Model on the other hand may only send notifications to the View. If anything, PureMVC is overly permissive in it's allowing Commands to be triggered by notifications from the Model.

Keep in mind that the View tier has no other purpose in life than to allow the user to interact with and update the Model. Therefore it is completely acceptable that the Mediator would collaborate with any Proxies necessary to fulfill its use cases. The place in the View tier that you're concerned about remaining portable is the view components themselves. The Mediators perform this decoupling for us, allowing us to write portable view components that know nothing of the PureMVC apparatus to which they are attached.

When we talk about loose-coupling (and the effort expended in to achieve it), it is important to consider which couplings we're most concerned about. If you're feet are tied, but you're neck is in a noose, which coupling is more important to loosen first? If you wear your self out untying your feet, you may collapse on the noose when you're done. But at least you're feet will be unbound, right?

At the MVC level the coupling that you want to concern yourself with most is not how strongly your View is coupled to your Model, but visa versa. You want to ensure that your Model knows nothing about the rest of your application and keeps itself focused on the domain model.

Unless you are specifically setting out to write a view component that will be resold, (ala ILog Elixir), your greatest potential for reuse is in the Model. Always assume that the web client you write today will have desktop and mobile counterparts later. With the new version of AIR already running on many phones, this potential has never been greater that one Model tier library could be reused in all three applications. The form factors and use cases will probably be quite different in these companion apps.

You might reuse some of the same view components, but the Mediators will likely be unique to the application they're a part of and will not be good targets for reuse. But if you've abstained from letting your Model know anything about the rest of the app, then you can package it separately and use the same library in all your apps.

The other consideration that figures into whether to put Model tier interaction into a Command rather than a Mediator (on a case by case basis, not as an across the board practice) is DRYness. (i.e. Don't Repeat Yourself). When you have the same code in multiple places, then updating it requires visiting more than one actor; a bad maintenance legacy.

So if you have logic that you are triggering both from a button in one view component and from a keystroke grabbed in another, then you have a potential candidate for logic to be moved into a Command so that you can ensure that the same thing happens in both places.

-=Cliff>
¹ MVC Diagram attached, via Wikipedia

[Helmut Granda]

You might reuse some of the same view components, but the Mediators will likely be unique to the application they're a part of and will not be good targets for reuse. But if you've abstained from letting your Model know anything about the rest of the app, then you can package it separately and use the same library in all your apps.

I think this is more along the lines of what I was thinking. Something that can be reused even though the likeness of being reused is very minimal educating yourself to working this way might feel counterproductive at first but will have pay offs in the long run when your attitude towards development comes so natural on leaving your resources open for reusability.

Conceptually, there is nothing wrong with putting all of your application's Model tier interaction into Commands if it 'feels more natural' to you, except that it uses up way more cycles than necessary to get things done.

When you talk about cycles, are you referring to the processor/CPU usage? I mean if your application is toward computer-savvy users you might be very likely to get users with "good" computers that wont have any issues processor intensive applications. No that this should be the mentality towards all applications, I mean more as this should be a secondary thought than a rule?

[puremvc]

When you talk about cycles, are you referring to the processor/CPU usage? I mean if your application is toward computer-savvy users you might be very likely to get users with "good" computers that wont have any issues processor intensive applications. No that this should be the mentality towards all applications, I mean more as this should be a secondary thought than a rule?

Yes, I meant actual CPU cycles, resulting from all the extra work that happens. I learned to program in machine language on a 6502 system with less than 2k of RAM. That ingrained in me a mandate to always understand what the shortest path is, even if maintainability and other factors cause me not to implement it. But it always carries weight in the equation.

You can expect people to have 'good computers' these days, but that doesn't mean that the operating systems on those machines are yielding to the user anything like the actual horsepower of the machine.

For instance, I've got this HP TouchSmart that I bought for my recording studio. It came with Vista. And despite Intel's rating of the duo-core processor being 4.5 out of 5, and my recording software's ability to effectively utilize multiple cores for audio rendering, it is still dog slow. I've done everything I can to optimize it but it's like trying to get blood from a turnip. I've just spent an inordinate amount of time reading Ars Technica's 15 page novella on Windoze 7 to try and decide whether to upgrade, but it doesn't look like its worth it. So here I have a cutting edge, touchscreen computer with very little installed on it other than the OS and some recording software and drivers.  There may be many little 'power user tweaks' that could be done to try and optimize it, but really, there is only ONE REASON why this computer is so slow: For years, Microsoft's developers have adopted the same attitude: "people have good computers these days, let the hardware do the heavy lifting".

To this I say, there is never an excuse for writing and shipping sloppy code based on this principle. I'm not saying write to the shortest-path always. That can make the code unmaintainable, and it often looks like it was written by aliens. I'm just saying be aware of it and be sure there is a good reason not to take the shortest path before building something more circuitous just because it 'feels more natural'.

There is an attractive simplicity to a one-to-one relationship of Commands to Model interactions, and it is certainly possible to implement to that plan. If you have a large and/or distributed team working on your codebase, this might be the best because its easy to get everyone on the same page about what they're doing, since the same rule is applied everywhere. It compartmentalizes things and makes it less likely that people will step on each other's toes as they work because there are separate files for the myriad Commands. But if one person or a small co-located team is doing the architecture and development, then you might want to reconsider the approach, and implement Commands on the basis of DRYness/reuse. Don't consider Mediator / Proxy relationships to be tainted love. They are perfectly acceptable, though not as immediately obvious as a controller folder full of Commands.

-=Cliff>

[Helmut Granda]

This is the main reason why I was thinking of the use of commands as the main router for communication through the application:

There is an attractive simplicity to a one-to-one relationship of Commands to Model interactions, and it is certainly possible to implement to that plan. If you have a large and/or distributed team working on your codebase, this might be the best because its easy to get everyone on the same page about what they're doing, since the same rule is applied everywhere.

but you are correct, the end user is the most important on the software development and there has to be a compromise on the development rather on the assumption that the end user will have the best system available.