According to MVC definition from wikipedia:
“Model View Controller (MVC) pattern creates applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements.”
But if we search for MVC frameworks we found many variants: MVC1,MVC2,MVC3,MVP,MVVM and PureMVC.
The question is which one is the best to use?
As any debate like that, there’s no unique solution, it depends on many factors.In this article we try using JavaDepend to discover PureMVC indepth, and talk about the main difference between it and the other variants.
PureMVC was popularized first by Flex and Flash developers, but it was ported after to many other langugages.The following GWT sample use the java PureMVC framework, let’s analyze it to explore PureMVC concepts.
PureMVC basic Concepts
Here’s the structure of the project
This structure shows the main PureMVC concepts:
- Facade:Initializes and caches the core actors (model, view, and controller) and provides a single place to access all of them.
- Proxies:Expose an API for manipulating the data model ,including data retrieved from remote services.
- Mediators:The view communicate with their Mediators using Events and exposing some properties for the concrete Mediator to inspect or manage. A Mediator connects a View Component with its data and communicates with the rest of the system on its behalf.
- Commands:A Command may retrieve and interact with Proxies, communicate with Mediators, or execute other Commands. Commands are often used to orchestrate complex or system-wide activities such as application startup and shutdown.
The PureMVC best practices encourage developers to put each actor into a specific namespace , to modularize better the application.
Here’s the graph representing the communication between all namespaces.
There’s no dependency cycle, it’s well layered what makes it very clear and simple to understand.
The matrix gives us more details about dependency weight between all namespaces.
The PureMVC glue
To go deep inside the sample let’s discover the dependency graph between all classes
What’s interesting in this dependency graph, is that almost all classes uses INotification.
PureMVC use the publish-subscribe pattern to communicate between all actors(Model,View,Controler), and for this reason INotification is mainly used, and to check that let’s discover the most popular types, for that we can use the TypeRank metric.
SELECT TOP 100 TYPES ORDER BY TypeRank DESC, TypeCa DESC
The three most popular types concern notification mechanism, what’s proof that this concept is the glue of PureMVC framework, almost all communication between actors use notification, that make them less coupled.
Publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers. Published messages are characterized into classes, without knowledge of what, if any, subscribers there may be. Subscribers express interest in one or more classes, and only receives messages that are of interest, without knowledge of what, if any, publishers there are.
This allows asynchronous, event-driven communications between the actors of the system, and also promotes a loose coupling between those actors, since the subscriber never needs to have direct knowledge of the publisher.
For our sample we can search for all classes using Notifier class to notify other actors.
SELECT METHODS FROM JARS "PureMVC" WHERE
Almost all actors: Mediators,Commands and proxies use the notification mechanism to communicate with each others.
Here’s a concrete example of adding a new user from view.
In this sample the mediator ask the proxy to add a user and after send a notification to inform all other components that a user was added.
What’s interesting to note here is the fact that the mediator communicate directly with the proxy, in PureMVC, proxies cant act as subscribers, and can only publish notification.
Inside PureMVC Concepts
- Facade is singleton
If we search where the facade is instantiated
SELECT METHODS WHERE
DepthOfCreateA "org.puremvc.java.multicore.patterns.facade.Facade" == 1
Only one static method getInstance instantiate it, but this method has one parameter, so we can create many facades, each component has its own singleton facade identified by a name, and it’s why we talk about PureMVC MultiCore.
- Facade Initialisation:
SELECT METHODS WHERE
The facade initialize all other actors.
- Facade and notification:
The facade caches all actors, and when a notification is published, the facade notify all observers.
Let’s search for all methods used by DeleteUserCommand, the command responsable of deleting a user.
SELECT METHODS WHERE
The command doesn’t communicate directly with other components, except for the proxy as we observed before.
SELECT METHODS WHERE
Like Commands, mediators use mainly notifications to interact with other classes except for proxies.
The question that makes a difference using PureMVC and gives us three more other variants is:
who communicate with the proxy?
Here we can differentiate between three ways used by developers using PureMVC:
- Only Commands use proxies: we suppose that only commands have to abstract the logic of the application, this solution makes the code more reusable, for example deleteuser could be used by many classes, and if this logic exist in mediator instead of command, we have to duplicate the code if another mediator need to also delete a user.
- Commands and mediators use the proxy:For our sample it’s what happens.The AddUser is invoked from a mediator and the deleteuser from a command.
- Only Mediators use proxies and commands are used only for startup: Some developers prefer not use Commands and use only Mediators, to not add more classes and maybe more complexity to the code.
The main difference between PureMVC and the other variants, is the way that all actors communicate with each others, PureMVC choose the asynchrounous and the less coupled solution.