Your SlideShare is downloading. ×
0
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
PureMVC
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PureMVC

3,247

Published on

Why use an application framework? …

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,247
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
83
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PureMVC<br />GUYA.NET<br />
  • 2. Why use an application framework?<br />Bottom line - Help us to be more efficient, more dynamic, less error prone.<br />Good for parallel development (multiple developers).<br />Patterns force good design.<br />Code for the future - Easier to make changes and update.<br />Enhance performance.<br />Faster for new team members to start along.<br />GUYA.NET<br />
  • 3. Spaghetti? – No thanks!!!<br />GUYA.NET<br />
  • 4. GUYA.NET<br />
  • 5. Image Credit<br />GUYA.NET<br />
  • 6. Why choose PureMVC<br />I like it :)<br />Highly documented.<br />Community - Been out there long enough to prove it strength and maturity.<br />More approachable, easier to understand.<br />Out of the box better support for modular applications.<br />Not, so old and somewhat obsolete (cairngorm).<br />Handle views better using mediators.<br />Open sourced with a good license (CC).<br />GUYA.NET<br />
  • 7. Why choose PureMVC, continues<br />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’)<br />Scalability – Cope with big applications.<br />Flexibility – Easy to extend.<br />Clean implementation – Hides the singletons, uses a main Façade.<br />GUYA.NET<br />
  • 8. The PureMVC Meta Pattern<br />MVC<br />Singleton<br />Command<br />Mediator<br />Observer<br />Value Object<br />GUYA.NET<br />
  • 9. GUYA.NET<br />
  • 10. Main Actors<br />Model – Proxies hold the model VO’s, also take care of remote services.<br />View – Mediators encapsulate unaware UI components.<br />Controller – Commands, can be think of as encapsulated autonomous functionality untied to an owner.<br />GUYA.NET<br />
  • 11. Notifications - Internal communication<br />PureMVC uses notification (Similar to Flash Event).<br />All actors can send and listen to notifications.<br />sendNotification(name, body, type);<br />Data can be sent along inside a notification’s body.<br />GUYA.NET<br />
  • 12. Model - Proxy<br />Encapsulate the data object.<br />Interact with remote services.<br />Provide an API to access the data and the proxy functionalities.<br />Send notification to the rest of the system. e.g. DATA_HAS_CHANGED<br />Can use delegates, helpful when many proxies use the same remote object.<br />GUYA.NET<br />
  • 13. View – Mediators<br />Mediators interact with the public API of the view components.<br />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.<br />Sends and receives notifications to communicate with the rest of the application.<br />Shouldn’t handle large amount of notifications.<br />Should hold no complicated logic (Business logic belongs to commands)<br />facade.removeMediator( this.getMediatorName() );<br />GUYA.NET<br />
  • 14. Controller - Commands<br />Commands handle the business logic of the application.<br />Commands are mapped to notifications and are never called directly. registerCommand( LOGIN, LoginCommand );<br />Coordinates the Model and View states.<br />Used for complex actions and business logic, e.g. transactions.<br />GUYA.NET<br />
  • 15. Communication best practice<br />Mediator -&gt; Proxy (can reference a proxy for data. One way coupling)<br />Mediator -&gt; Command -&gt; Proxy (Better) (Proxies don’t handle notifications)<br />Mediator -&gt; Notification/Command -&gt; Mediator<br />Proxy -&gt; Notification/Command -&gt; Mediator<br />Commands -&gt; Mediator/Proxy (can interact with mediators and proxies).<br />GUYA.NET<br />
  • 16. Demo<br />GUYA.NET<br />
  • 17. Lets see some code<br />GUYA.NET<br />
  • 18. PureMVC cons<br />Platform/Context independent – Doesn’t utilize Flash/Flex capabilities. E.g. not using Flash’s events system – has it’s own notification system.<br />Still uses a lot of singletons (Hidden in a easy to use façade).<br />Not the best for unit testing.<br />For max flexibility everything is typed as an Object – Lots of casting needs to be done.<br />GUYA.NET<br />
  • 19. Can we SCRUM it?<br />By nature the architecture encourage separation of concerns - Model, View and Controller.<br />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. <br />Easier to separate stories into tasks since things are separated by default.<br />In the end of the sprint we’ll have much more efficient code with less bugs.<br />Will be much easier to debug in these final critical hours (Even with other people code).<br />GUYA.NET<br />
  • 20. Implementation - Our main challenges<br />Making changes and being dynamic is always more difficult. Especially when things are relatively working.<br />A lot of code will be thrown and/or refactored.<br />A lot of proprietary knowledge will be thrown, In favor of common best practices.<br />GUYA.NET<br />
  • 21. More about performance<br />Things will happen when it should and only when it should. E.g. setting a dataProvider only once instead of unneeded multiple times.<br />We will be able to kill heavy UI components, and even unload modules at runtime. Currently we can&apos;t do it since unload/killing component isn&apos;t freeing their memory. Mostly because it&apos;s still referenced in multiple places of the application.<br />GUYA.NET<br />
  • 22. Bonus – Flex PMD<br />http://opensource.adobe.com/wiki/display/flexpmd/FlexPMD<br />Flex Builder PMD tool: http://flashmattic.blogspot.com/2009/09/flexpmd-from-flex-builder.html<br />GUYA.NET<br />

×