PureMVC is an MVC framework where you dont get to work with the Model-View-Controller part of it at all. The MVC part of the framework are Singletons that are accessed by Proxies, Mediators and Commands. There is a fourth Singleton, a Facade, which enables the Proxies, Mediators and Commands to communicate with each other in a meaningful way.

• Model - accessed by named proxies
• View - accessed by named mediators
• Controller - accessed by named command objects

The Facade exposes methods to add, remove and get; proxies by name, mediators by name and commands by name. It also has a method to send a notification (another pattern). The framework intends that the developers do not interact with the MVC structure directly, instead using names and the central Facade to interact with the MVC structure via the secondary patterns of proxy, mediator and command.

The mediator interacts with the View's data via notifications. A mediator can be interested in multiple notifications. The proxy follows the same mechanism, it interacts with the Model via notifications. The controller contains mappings between commands and notifications. A command may retrieve and interact with a proxy, notify a mediator, or execute another command object. As per the GoF command pattern there is a SimpleCommand and MacroCommand where the latter's execute method can implement the execute interface on an aggregate of SimpleCommand's execute method.

Notifications are done through the Observer pattern. The observer carries a reference to the object that wants to be notified and the method that the notification will be broadcast too. It is up to the View to manage the mapping of notification names to observers when a notification is sent.

So what are the pros and cons of using this? The pros is that it is well defined as per the GoF book which has become the franca de lingua for software developers. The downside of the Gang Of Four book usage is that it causes abstraction proliferation where in many instances a simple procedural or concrete object that cracks a developers ribs is simpler, easier, less fragile and less confusing. Another downside is that pureMVC code is not portable unless you use pureMVC again. From experience, I have already seen that a classically OOP designed system bears no relevance in a pureMVC system, essentially removing any portability for that code to other systems. This system also suggests that it is over-designed as the actual MVC structure is abstracted away from the developer into proxies, mediators and command objects. Then again, this level of design and abstraction may prove more maintainable in the long run. We shall certainly find out.

Note It reminds me more of a CORBA system than an MVC one. I worked on a large CORBA system several years ago. It was solving the issue of multiple desktops running the same application. Apache and HTTP made that whole set up redundant. I recall a website was placed over the top of the CORBA system since so much work had gone into the underlying structure. Not sure that pureMVC's level of abstraction is solving a known problem domain, as I have worked with smaller MVC frameworks that did not run into blending of responsibility issues.

Model

The model is interacted with through Proxies which can send notifications, but do not receive them. A command will operate on a proxy object directly through a method call, such as, demoProxy.changeThis(Obj), and the proxy, realizing that its state has changed, can then send out a notification for other mediators and commands to react to its new state.

View

The View is interacted with by mediators which can have multiple notifications (think events) they are listening to. Mediators can send and receive notifications, as well as allow other parts of the system to ask what notifications they are interested in.

Controller

Commands are mapped to notifications by the central Facade. The controller responds to notifications and, based on notification name, and the mapping, will fire the command and execute it. A command interacts with a proxy (model) directly through a method call. A command can also interact with a mediator (view) directly or through a notification. The direct manipulation of a mediator can make the controller and view tightly coupled, but is possible within the system.

Since we are using PureMVC we recently had a heated discussion over whether to name the value object with a VO on the end. A kind of Flex form of Hungarian notation. One of the issues is names clashes, despite having different package names dividing up the namespaces so that each object name is different the IDE usually just displays them in the dot completion drop down as just the object name. Which can cause confusion.

I would prefer not to have to name everything with some form of end descriptor such as Command, Mediator, or Proxy but PureMVC breaks the functionality up so much that the naming ends up becoming repetitive. Also, because of the heavy use of patterns the object names tend to be meaningless unless the command, mediator or proxy is added onto the object name.

For instance a Command object is one with an execute() method that is requester agnostic and the object asking for that operation being performed doesn't know or care what the command object is doing, or going to do.

Value objects are slightly different. In the PureMVC system they are the closest thing we have to classical OOP objects. They describe a 'something' with private variables and getter and setters. So if any component in the PureMVC system should be named with a hard descriptor, it is the value objects.

A counter argument is that adding VO to the end of an object name aids readability. I consider most of this kind of readability as code litter. The reason we don't use Hungarian anymore is that it was a big mess. The convention of underscoring private variables is unnecessary in languages that have the private modifier to variables and functions. Underscoring their variables names is meaningless. So it is with package namespaces and object names.

The best argument for making the value objects carry the VO is that the IDEs tend to lump everything together in the dot completion drop downs. In my opinion this isn't a good enough argument to demand the addition of the VO identifier.

Software teams tend to be democratic to an extent and in this issue the team is slightly split. Programmers tend to treat their writing of code with care and make sure the formatting is all clean, evenly spaced and to their aesthetic liking. So something as simple as adding VO to an object descriptor can evoke some heated discussion and heels being dug in. Such is the fun of software development in teams.