7.5. Flex and Hibernate Integration Expectations
This section focuses on what should be expected when integrating Flex and JPA or Hibernate and not what is necessarily present in the adapters today. It attempts to put together a set of requirements that could be used as the starting point to evaluate adapters and solutions that make Flex and JPA/Hibernate work together smoothly.
For every solution that integrates Flex and JPA or Hibernate, you should consider supporting the following:
Lazy loading
Incremental updating
Managed CRUD operations
Non-invasive value addition
Lazy loading is by far the most important of the list of expectations. JPA and Hibernate allow you to lazily fetch and load referenced entities, providing performance gains and optimal resource utilization. Say that a person has many friends, where each friend is a person. Logically, each friend, who is a person, will have friends and that way the connected list could go on to an infinite depth. There is popular belief that any two people are only six such links apart. So, let's assume that six links is the maximum depth it can descend to. Now if an initial list of the 100 most connected people is fetched and you desire to have access to their extended network, you have two simple choices in hand:
Either you eagerly fetch the 100 people and their entire networks up to six levels of depth, or
You fetch the 100 people only and do not load anything from their networks. You only send along handles or references that can be used to walk the interconnected network and fetch the required data later when needed.
It doesn't take more than a couple of minutes of thinking to go with the second choice to load connected objects lazily. You know that fetching immense amounts of data up front creates a performance drag and eats up more memory than should be used up. Also, it's almost certain that many interconnected network branches will not be walked at all.
Once a collection is loaded, leveraging the lazy optimization, a user manipulates this data on the client, which in the case of Flex is outside the JVM. Say that a user plays with the list of 100 person objects from the earlier illustration and modifies 5 of them. Again, you have the choice to either send the entire collection back or just send the modified set. Going with the modified set seems prudent, but this imposes its own complexity. If you send only modified sets, you need to a have reference to the original set. At least copies of the original elements that were modified will be required at the time you reconcile the changed entities at the persistence layer.
When you send the changes back to the persistence layer, you need to make sure that the entities are in a form and style that JPA and Hibernate can consume and work with. That's theoretically not asking for much, as JPA and Hibernate impose few restrictions on what entities should be like. Often, associated metadata or a few annotations are enough for the persistence layer to manipulate these entities. Java bean–style getter and setter methods and private properties are recommended, but even that's not a requirement. The only requirement is to have a no-argument constructor so that reflection could be used to instantiate these objects. Therefore, it's desirable that the adapter not impose restrictions beyond the simple standard ones either. You will learn later in this chapter that this problem, which appears benign at first, occurs quite commonly in adapters, creating oddities and restrictions on leveraging existing persistence layers.
Many Flex applications that interact with persistence layers indulge in CRUD operations. Developers tend to reinvent the wheel every time they have a new application, even when their interactions are restricted to CRUD. Why then should adapters and assemblers not support this natively and provide ready to use convenience methods? Although some believe that adding CRUD isn't an adapter's responsibility, it is still a valuable feature to have and could be supported through an independent but related plug-in. In a section titled "Managed Entities for Flex Applications," a few aspects of CRUD and managed entities are brought up.
Adding managed entity features and CRUD could ask for a client side API to provide a standard interface at the Flex end. While this may become a necessity for consistent behavior, adapters should impose as minimal as possible dependency on the client-side code. If a plain vanilla adapter that only sends up collections is asking you to use a specific client-side library and API, then I would recommend looking it over very carefully. Remember that every bit of extra API-based restriction makes your code brittle as far as refactoring, maintenance, and extension is concerned.
In all the cases listed above and others, the general expectation should be that, as far as possible, an adapter is non-invasive and does not break the standard contract either of the server-side persistence layer or of the client-side application. The task of the adapter is to extend the scope of the persistent entity beyond the JVM, and all it should focus on is the transition in form as entities move back and forth between the two layers.
In the next section, some of the ideas presented here are analyzed in the context of implementation.