Accessibility

Table of Contents

  1. Introduction
  2. Why use Flex Data Management Services?
  3. Conceptual overview of Flex Data Management Services
  4. Building the client's view of the domain model
  5. What about complex object models?
  6. What about large data models?
  7. Building a scalable data services application

Architecting RIAs with Flex Data Management Services

Building the client's view of the domain model

One of the first important decisions in designing any RIA is choosing the set of objects whose state is maintained on the client. For a Flex Data Services application, these will be a set of ActionScript objects that map directly to a related set of Java objects on the server side. The server and client-side objects will typically have the same set of public properties with the same names.

The objects must serialize to each other using Flash Player serialization rules. Flash Player supports efficient serialization of Java to ActionScript and vice versa. It requires simply that:

  • The ActionScript and Java objects have the same set of public properties.

    Note: These are an extension of JavaBean properties. See below.

  • The ActionScript class is annotated with a directive that tells it the name of the remote Java class to serialize this class to, for example:

    [RemoteClass(alias="someJavaPackage.SomeJavaClass")]

If you do not set the RemoteClass metadata on an ActionScript class, it will be serialized to an object that implements the java.util.Map interface on the server side. Similarly, any Java class that does not have a [RemoteClass] tag with an alias mapped to it will be serialized into an anonymous object on the ActionScript side. Using anonymous objects on either or both sides is a quick way to get started using Data Management Services, although this approach lacks the compile-time error detection, which can be extremely beneficial when working on a large project that undergoes lots of changes.

When serializing an object from Java to ActionScript, you can consider any public member variable or JavaBean property on the Java class to be a property to send to the client to populate a property on an ActionScript object. In addition, if the type implements the Map interface, the entries in a Map are considered properties. ActionScript itself has a more robust concept of properties, which encompasses dynamic Objects (similar to Maps in Java) and strongly typed objects. A strongly typed object can either represent a property as a public member variable or through a pair of get and set methods you define with a special syntax.

This design makes it pretty easy to make Java and ActionScript classes that correspond to each other. If you have an existing Java domain model, you may well be able to map it directly to ActionScript objects and expose these on the client, although this is not always a best practice. A tool that generates an ActionScript class from a Java class with optional annotation will be forthcoming to help keep strongly typed classes in sync between the client and the server.

In some cases the Java objects used by Data Management Services could be your existing application domain objects or—when more security or server-side processing is required—they may be wrappers on your application domain objects. At one extreme is the EJB model, where the client interface is explicitly decoupled from the domain model. Data Management Services works equally well in these environments where such wrapper objects expose a carefully controlled slice of the domain model. But for rapid development, no such wrapping layer is required.

Frequently, the objects that are shipped to the client follow the data transfer object pattern where they primarily expose state. However, these classes are also convenient and natural places to embed portions of your application's functionality you need to access on the client.

The top-level instance managed by each destination must have one or more identity properties, which uniquely identify that item within the other top-level objects managed by that destination. The ID properties can be assigned on the client but are typically assigned when the item is created on the server. In this case, the ID property values are received by the client when the response to the commit is received. If your application needs to be aware of the ID, you can simply bind to the ID property of your managed instance. You can also listen for the object change event or listen for the result event on the data service.

Data Management Services ensures that there is only one managed instance of each object on the client with a given ID for a given destination. You may issue two fill statements, each of which returns overlapping sets of items. If the IDs of the items match, Data Management Services ensures that the instances are the same.

Page 4 of 7
Previous Page
Next Page