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. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access