4.5 Understanding the Active Data Model

One of the key simplifying benefits of using ADF Business Components for your business service implementation is the application module's support for an "active data model" of row sets. For developers coming from a Forms/4GL background, it works just like you are used to in previous tools.

4.5.1 What is an Active Data Model?

Using a typical J2EE business service implementation puts the burden on the client layer developer to be responsible for:

Invoking service methods to return data to present,
Tracking what data the client has created, deleted, or modified, and
Passing the changes back to one or more different service methods to validate and save them.

The architects that designed the ADF application module recognized that this retrieve, create, edit, delete, and save cycle is so common in enterprise business applications that a smarter, more generic solution was required. Using the application module for your business service, you simply bind client UI controls like fields, tables and trees to the active view object instances in the application module's data model. Your UI displays automatically update to reflect any changes to the rows in the view object row sets in that data model. This includes displays you create using JSP or JSF pages for the web or mobile devices, as well as desktop-fidelity UI's comprising windows and panels using Swing. This "active" data notification includes changes to the data model that are the result of work performed directly or indirectly by your custom business service methods, too.

Under the covers the application module component implements a set of generic service methods to enable the active data model facility in a Service Oriented Architecture (SOA). The client layer simply uses the ADF Business Components interfaces in the oracle.jbo package. These interfaces provide a higher-level API that lets you think in terms of row sets of rows in the data model whose contents your end-user needs to search for, create, delete, modify and save. They hide all of the lower-level generic SOA-method calling complexity. What's more, when you build UI displays that take advantage of the ADF Model layer for declarative data binding, you generally don't need to write client-side code at all to work with the active data model. Your displays are bound declaratively to view objects in the data model, and to custom business service methods when you need to perform any other kind of logic business service function.

4.5.2 Examples of the Active Data Model In Action

Consider the following three simple, concrete examples of the active data model in action:

New data appears in relevant displays without re-querying: A customer logs into the SRDemo application and sees their list of open service requests. They visit some wizard pages and create a new service request, when they return back to their home page, the new service request appears in their list of open requests without re-querying the database.
Changes caused by business domain layer logic automatically reflected: A manager edits a service request and assigns a technician to the case by picking their name from a poplist list of values page. Business logic encapsulated in the ServiceRequest entity object in the business domain layer behind the data model contains a simple rule that updates the assigned date to the current date and time whenever the service request's assigned to attribute is changed. The user interface updates to automatically reflect the assigned date that was changed by the logic in the business domain layer.
Invocation of a business service method re-queries data and sets current rows: In a tree display, the user clicks on a specific node in a tree. This declaratively invokes a business service method on your application module that re-queries master detail information and sets the current rows to an appropriate row in the row set. The display updates to reflect the new master/detail data and current row displayed.

Without an active data model, the developer using a less clever business service implementation approach is forced to write more code in the client to handle the straightforward, everyday CRUD-style operations. In addition, to keep pages up to date, they are forced to manage "refresh flags" that clue the controller layer in to requesting a "repull" of data from the business service to reflect data that might have been modified. When using an ADF application module to implement your business service, you can focus on the business logic at hand, instead of the plumbing to make your business work as your end users expect.

4.5.3 Active Data Model Allows You to Eliminate Most Client-Side Code

Because the application module's active data model feature ensures your client user interface is always up to date, you can typically avoid writing code in the client that is related to setting up or manipulating the data model. Oracle recommends encapsulating any code of this kind inside custom methods of your application module component. Whenever the programmatic code that manipulates view objects is a logical aspect of implementing your complete business service functionality you should encapsulate the details by writing a custom method in your application module's Java class. This includes, but is not limited to, code that:

Configures view object properties to query the correct data to display
Iterates over view object rows to return an aggregate calculation
Performs any kind of multi-step procedural logic with one or more view objects.

By centralizing these implementation details in your application module, you gain the following benefits:

You make the intent of your code more clear to clients
You allow multiple client pages to easily call the same code if needed
You simplify regression testing your complete business service functionality
You keep the option open to improve your implementation without affecting clients, and
You enable declarative invocation of logical business functionality in your pages.

Another typical type of client-side code you no longer have to write using ADF Business Components is code that coordinates detail data collections when a row in the master changes. By linking the view objects as you'll learn in the next chapter, you can have the coordination performed automatically for you.