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]
Print
Author Topic: VOs and data object in Proxy  (Read 11334 times)
shizny
Full Member
***
Posts: 31


View Profile Email
« on: March 08, 2008, 11:24:12 »

I've got this little xml database that stores user's login and password.  I have used code peek as an example of how to deal with multiple datastores using the abstractProxy.  Here is my question.  In the userProxy I have the data object set to an xmllist in the user proxy.  Should I take the additional step and create a UserVo class that is instantiated and set in the userProxy as a private variable, or is there no need to use a vo when I could return an xmllist from a get User function in the userProxy?


Logged
sectore
Courseware Beta
Full Member
***
Posts: 29



View Profile WWW Email
« Reply #1 on: March 09, 2008, 02:23:55 »

It might be helpful to use VOs dealing data in your app. So a Mediator can use a VO, e.g. UserVO, to populate its ViewComponent retrieving the Proxy. And the ViewComponent expects this type too.

Furthermore dealing with VOs gives you the possibility to replace your XML service with a Remote Service (e.g. AMFPHP) or anything else without changing the rest of the app. Because the getUser method in your UserProxy returns a type of UserVO and not a type of XMLList. That means the caller (a Mediator, a Command or another Proxy) will be independent of the result of your service.

Last but not least a ViewComponent can bind the VO using the [Bindable] metatag to update itself without breaking rules so long as your app is based on Flex  ;) .

-sectore
Logged
shizny
Full Member
***
Posts: 31


View Profile Email
« Reply #2 on: March 09, 2008, 12:28:42 »

thanks for the insight.
Logged
shauno


Email
« Reply #3 on: March 11, 2008, 12:34:23 »

Also, if you change the structure of your XML (maybe everything gets nested a little deeper or node names change) you only have to edit one file - the rest of the app remains unchanged. This has saved my bacon a bunch of times :)
Logged
Pages: [1]
Print