Flex Pasta

No Chain Events: Transfer Object Pattern

Cairngorm users know a chain event:  a way to execute, in order, multiple remote requests such as http, remote object, or web service calls.

 The Good

• Executes multiple requests in order
• Ability to use data returned from an earlier event on the chain to make a request for a subsequent event on the chain

The Bad

• When events are chained that do not need to be in sequential order
• When events are chained that do not need a previous result’s data

The Ugly

• A chain event is a performance hit!  It makes one request, waits for the result, then makes the next, waits for the result, and so on.  It’s bad for the end user to have to wait for all these events to fire in order.  The problem is compounded when chain events are over used.
• The code.  Using chain events with Cairngorm involves ugly code that makes bugs more likely.
• Business logic use cases are needed in more numbers and are more difficult to design, implement, and maintain.  For example, what happens when a 5 chain event incurs a fault abnormally during event 3?  What happens when event 2 comes back with a result, but it is not in the format expected?  How does a support team troubleshoot a user’s problem when they’re failing on one part of a chained event?

One alternative option to a chain event is the Transfer Object Pattern.  Here are the goals of the Transfer Object Pattern:

• Reduce high method invokations by encapsulating the calls in a generic object.
• Reduce the chatiness of the application by eliminating requests across the network

Example:  From Chain Event to Transfer Object Pattern

The Chained Event:

Event 1: Call a remote Java method: public Customer doLogin(String username, String password) - It takes a user name and password and returns me a Customer object.

Event 2: Given the Customer object from event 1, I now use it to call public List<Accounts> getCustomerAccounts(Customer customer) -  This method takes the customer object I got from Event 1, and then retrieves the customer’s list of Account objects.

The Transfer Object Event:

The transfer object pattern has only one event.  It will call a remote Java method called public LoginResult doLogin(LoginRequest loginRequest)

LoginRequest would look something like this:
public class LoginRequest
{
private String username;
private String password;
}
…getters and setters….

The LoginResult would look something like this:
public class LoginResult
{
private Customer customer;
private List<Account> accountList;
}
…getters and setters…

The workload is now away from the Flex chained event and put on Java.  In this case, I only have one request/response at login, rather than two.  This improves performance and wait time for the end user.  It also makes my Flex code less cluttered(without all those “what ifs” for the chained event).  The Java code needs some modifications but is still simple and easy to maintain.  Adding on is also very easy.  Say I also want to return a list of statement objects at login.  I simply add the new list object to the LoginResult class without having to add the plumbing for more remote calls.  There is minimal work in Flex to get the data I need and without the clutter of adding on to a chain event.

The Transfer Object pattern is an example of another approach to a chain event.  It may not work in all cases, but is worth considering!