Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Author Topic: Data Binding & PureMVC  (Read 9308 times)
Posts: 1

View Profile Email
« on: August 04, 2011, 03:34:52 »

Hi - as my user type clearly states.  I am a complete Newbie to PureMVC.  However I have experience with other MVC frameworks such as Cairngorm.

OUR CTO/Architect is getting very close to pulling the plug on PureMVC within our enterprise Silverlight application because we can't seem to wrap our arms, minds, etc. around how data binding can really working with PureMVC.  We have the first large piece of our app using PureMVC and data binding but his concern is that the data binding and notification system within PureMVC seemed to be mechanisms doing similar things in parallel.  We find it hard that the data binding seems to be working outside of the PureMVC framework.

I've done lots of reading and I've seen posts about how the two can certainly work together and that data binding does not need to be sacrificed.  However, we are still struggling with it. 

Any tips, links, and additional information on how data binding can work in conjunction with PureMVC would greatly be appreciated!  I've looked at some of the original sample apps and I see data binding being used and the glue being the mediator but I'm still a bit confused.
Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #1 on: August 05, 2011, 02:21:03 »

In platforms that support it, Data Binding is appropriate inside view components, but not across the Model/View tiers.

In a PureMVC application, your Proxy may receive data from the server and send out a notification. Then a Mediator might hear that notification, take the data from the notification (if it was placed in the body) or retrieve the Proxy and get the data, then set it on the view component via a public property or method exposed by the view component. Then the view component may use data binding to move that data into form fields, data grids or whatever. The user may then modify the data and dispatch an event that the Mediator listens for and responds to by taking the data from the view component (or a property of a custom event), and in turn either invokes a Proxy method to send it back to the server, or perhaps sends it off in a notification to be validated or massaged first, and then passed on to the Proxy from the Command.

So folks who love some Data Binding will say "Oh, but wouldn't it be better to bind the view components directly to the data setting in the Proxy? Why have PureMVC do a 'bucket-brigade' carry of the data back and forth from the Model to the View when magical data binding is available?"

The answer(s) to that is that PureMVC decouples your view and model, reducing dependencies and making both more independently reusable. And portable. The language you're implementing in today may support Data Binding and any number of other whiz-bang features, but when you need to pull off an Android or iOS version, it may not work quite the same way. All those platform specific features you coupled your self to come back to bite you. It is a given when porting to another platform that you will have to write the view components and services from scratch. But if you've followed the PureMVC paradigm and the platform you're porting to is supported by PureMVC, then all your actors and their roles, responsibilities and collaborations will pretty much remain the same differing only in the syntactic sugar of the target language.


Pages: [1]