PureMVC

22
PureMVC GUYA.NE T

description

Why use an application framework? Why choose PureMVC? The PureMVC meta pattern PureMVC cons Can we SCRUNM it?

Transcript of PureMVC

Page 1: PureMVC

PureMVC

GUYA.NET

Page 2: PureMVC

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

Page 3: PureMVC

Spaghetti? – No thanks!!!

GUYA.NET

Page 4: PureMVC

GUYA.NET

Page 6: PureMVC

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

Page 7: PureMVC

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

Page 8: PureMVC

The PureMVC Meta Pattern

• MVC• Singleton• Command• Mediator• Observer• Value Object

GUYA.NET

Page 9: PureMVC

GUYA.NET

Page 10: PureMVC

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

Page 11: PureMVC

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

Page 12: PureMVC

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

Page 13: PureMVC

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

Page 14: PureMVC

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

Page 15: PureMVC

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

Page 16: PureMVC

Demo

GUYA.NET

Page 17: PureMVC

Lets see some code

GUYA.NET

Page 18: PureMVC

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

Page 19: PureMVC

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

Page 20: PureMVC

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

Page 21: PureMVC

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

Page 22: PureMVC

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