Chapter 3. Modelling the Domain

You must have some way of representing the basic data that your app will manage and, in the OOP world, that usually takes the form of some class with typed properties. There are lots of pressures that guide the ultimate implementation of your domain model entities in a client application. For instance, if you are using LCDS, BlazeDS, or WebORB, you can create classes on the server that map property for property to corresponding classes in the client. When a Java service sends one of these classes in a result, the ActionScript version of that class shows up already populated in the client and there is no need to parse the result onto an object yourself. Or you might receive JSON or XML from a REST service and programmatically convert it to typed ActionScript objects in the client when you receive the result. And using Flex and AIR, you might want those objects to have bindable properties so that View Components that use them as data providers can be updated when they change. A key thing to remember is that these classes should not know the architecture framework classes (PureMVC) or the View Component framework (Flex). These classes should stick to representing data. They might use collection types defined by Flash or Flex (such as Vector or ArrayCollection), but never Buttons, DataGrids, or other display list objects.

Designing the Schema

Earlier, we thought through the entities that the StoryArchitect application will concern itself with managing. ...

Get ActionScript Developer's Guide to PureMVC now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.