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: Best practices for LSO and models  (Read 8615 times)
Posts: 1

View Profile Email
« on: March 20, 2008, 12:45:12 »

I'm new to puremvc, flex, and actionscript.  I have been a programmer for a while so I've picked up most of it pretty easily.

I'm currently stumped in the area of using LSO's for your models within the puremvc framework.

Specifically, where do you put the code for the reading/creating/updating data from a LSO?  The proxy seems like the logical location. But, if I were to have a  complex data model with multiple different models and some custom classes living in an array collection, I'm having trouble figuring out a good way to save/update/delete a LSO without rewriting similar code for each proxy.     Something tells me a generic helper class that handles LSO actions for me is the way go, but I'm kinda weak right now in actionscript programming and would love to see how it's really done.

Another followup question I have is: Where is the best place to set the SharedObject up that I'd use to store all my data?  My hunch tells me you'd do this in the ApplicationFacade. Then, I could do the creation work there then access the LSO as ApplicationFacade.so.data.bar = "foo" in later code.

Please tell me if I'm going in the wrong direction or other suggestions for handling  data storage with LSO's.  I actually don't want to send user data back to the server as it will differentiate my software from competitors.  Any helpful code snippets appreciated.  Thanks.

Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #1 on: March 20, 2008, 05:03:11 »

A Proxy is your best bet.

Retrieve it when you need to access the data.

Cluttering your ApplicationFacade with data to be accessed statically is not a good plan.

Pages: [1]