The project I’ve been working on for a while now uses caching.  This means that the application will store the objects returned from the server in a DataCache and anytime objects are returned from the server, they are synced with the DataCache. This has the advantage of ensuring you’re always updating existing objects instead of just swapping objects out.  The reason that can be an advantage is because if you have views bound to those objects or, especially, properties of those objects, the view won’t end up bound to an object that no longer is relevant.  This is an important concept so I’ll elaborate.

Lets say you have an application that tracks contacts.  The Contact object has a number of properties and some of the properties are custom classes themselves, such as an Address class.  Your application displays the contact information for the contact and you bind the address view to properties of the address property, like this:

<s:Label id="street1" text="{contact.address.street1}"/>

At first glance, most people would think this is just fine.  But here’s the scenario where this becomes an issue:

Let’s say the contact application doesn’t cache the contact objects.  Instead, you just overwrite the original data with the updated data.  It’s fast and simple.  There is probably a var called contacts in a model that the rest of your application references to display information about the contacts.

You’re open the application and on startup, it fetches all the contacts.  You select one of the contacts to view all the details.  The label that displays the street binds to the contact you selected and displays the data.  Then your application fetches the contacts from the server again, in case someone else has made changes to the contacts.  This contact (we’ll call him Henry) lived on River Rd. but recently moved to live on Oak St.  While your application was open, someone else updated his address.  Now, when the application on your computer goes out and fetches the contact again, it replaces that object with the new contact object.  It’s the same information but a different object in memory.

Here’s where the problem comes into play.  The Label was bound to the street1 property of the address property of the original contact object.  That object still exists with the original address and street1 values, and the Label is still bound to it.  The new object that has replaced it happens to have the same name and contactId, etc. but ActionScript doesn’t assume anything so the label ends up showing out of date information even though you’ve fetched the updated information.

If the contact object was cached, what would end up happening is that the Label would bind to a property of the contact which was stored in the cache.  When the new object came back from the server, it would be sent to the cache to be syncronized.  The cache would find the contact object with the same contactId and copy values from the new object to the one already in the cache.  Any properties that are not base objects like String, int, etc. would need to be cached and synced as well.  So your Address instance associated with Henry’s Contact instance would be updated in the cache too.  That way, the Contact instance is always the same object in memory and the Address instance used for the address property would always be the same object in memory as well.

This method takes some more time to keep the objects up to date but makes it much simpler when it comes to referencing those objects throughout your application.  The flip side would be to do the basic swap of data, but use events to notify the rest of the application that things have changed and carefully deal with that change appropriately by reassigning references wherever needed.  That way would be much more complex on your part but could potentially be much faster than using the cache.