PureMVC

PureMVC
GUYA.NET

Why use an application framework?
Bottom line - Help us to be more efficient, more dynamic, less error prone.
Good for parallel development (multiple developers).
Patterns force good design.
Code for the future - Easier to make changes and update.
Enhance performance.
Faster for new team members to start along.
GUYA.NET

Spaghetti? – No thanks!!!
GUYA.NET

GUYA.NET

Image Credit
GUYA.NET

Why choose PureMVC
I like it :)
Highly documented.
Community - Been out there long enough to prove it strength and maturity.
More approachable, easier to understand.
Out of the box better support for modular applications.
Not, so old and somewhat obsolete (cairngorm).
Handle views better using mediators.
Open sourced with a good license (CC).
GUYA.NET

Why choose PureMVC, continues
Platform/context independent - no need to worry about updating Flex versions. Will be much easier to support more platforms (e.g. Pure Flash (mobile), Ajax, WPF, etc’)
Scalability – Cope with big applications.
Flexibility – Easy to extend.
Clean implementation – Hides the singletons, uses a main Façade.
GUYA.NET

The PureMVC Meta Pattern
MVC
Singleton
Command
Mediator
Observer
Value Object
GUYA.NET

GUYA.NET

Main Actors
Model – Proxies hold the model VO’s, also take care of remote services.
View – Mediators encapsulate unaware UI components.
Controller – Commands, can be think of as encapsulated autonomous functionality untied to an owner.
GUYA.NET

Notifications - Internal communication
PureMVC uses notification (Similar to Flash Event).
All actors can send and listen to notifications.
sendNotification(name, body, type);
Data can be sent along inside a notification’s body.
GUYA.NET

Model - Proxy
Encapsulate the data object.
Interact with remote services.
Provide an API to access the data and the proxy functionalities.
Send notification to the rest of the system. e.g. DATA_HAS_CHANGED
Can use delegates, helpful when many proxies use the same remote object.
GUYA.NET

View – Mediators
Mediators interact with the public API of the view components.
A view component is any UI component regardless of its complexity. Should encapsulate as much of its own states and operations, and expose as simple as possible API.
Sends and receives notifications to communicate with the rest of the application.
Shouldn’t handle large amount of notifications.
Should hold no complicated logic (Business logic belongs to commands)
facade.removeMediator( this.getMediatorName() );
GUYA.NET

Controller - Commands
Commands handle the business logic of the application.
Commands are mapped to notifications and are never called directly. registerCommand( LOGIN, LoginCommand );
Coordinates the Model and View states.
Used for complex actions and business logic, e.g. transactions.
GUYA.NET

Communication best practice
Mediator -> Proxy (can reference a proxy for data. One way coupling)
Mediator -> Command -> Proxy (Better) (Proxies don’t handle notifications)
Mediator -> Notification/Command -> Mediator
Proxy -> Notification/Command -> Mediator
Commands -> Mediator/Proxy (can interact with mediators and proxies).
GUYA.NET

Demo
GUYA.NET

Lets see some code
GUYA.NET

PureMVC cons
Platform/Context independent – Doesn’t utilize Flash/Flex capabilities. E.g. not using Flash’s events system – has it’s own notification system.
Still uses a lot of singletons (Hidden in a easy to use façade).
Not the best for unit testing.
For max flexibility everything is typed as an Object – Lots of casting needs to be done.
GUYA.NET

Can we SCRUM it?
By nature the architecture encourage separation of concerns - Model, View and Controller.
The layers are completely autonomous, e.g. the views are completely unconcerned about the rest of the app. Can be developed by different developers and be “tied” easily.
Easier to separate stories into tasks since things are separated by default.
In the end of the sprint we’ll have much more efficient code with less bugs.
Will be much easier to debug in these final critical hours (Even with other people code).
GUYA.NET

Implementation - Our main challenges
Making changes and being dynamic is always more difficult. Especially when things are relatively working.
A lot of code will be thrown and/or refactored.
A lot of proprietary knowledge will be thrown, In favor of common best practices.
GUYA.NET

More about performance
Things will happen when it should and only when it should. E.g. setting a dataProvider only once instead of unneeded multiple times.
We will be able to kill heavy UI components, and even unload modules at runtime. Currently we can't do it since unload/killing component isn't freeing their memory. Mostly because it's still referenced in multiple places of the application.
GUYA.NET

Bonus – Flex PMD
http://opensource.adobe.com/wiki/display/flexpmd/FlexPMD
Flex Builder PMD tool: http://flashmattic.blogspot.com/2009/09/flexpmd-from-flex-builder.html
GUYA.NET