3 ADF Model

This chapter provides a high-level overview of the ADF Model technology, including data controls, declarative bindings, and the ADF binding context, and shows how those components work with other parts of a rich enterprise application.

This chapter includes the following sections:

About ADF Model

Oracle ADF architecture is based on Model-View-Controller (MVC) design pattern. The model layer is supported by ADF Model, which is a declarative framework that binds user interface components in the view layer with the business services in the model layer and is integrated with JDeveloper tools.

ADF Model is a declarative framework that provides an abstraction layer between business services and the view and controller layers of an enterprise application that standardizes the way that components in those layers interact with each other. Figure 3-1 shows how ADF Model fits into an enterprise application.

Figure 3-1 Overall Application Architecture with ADF Model

Description of Figure 3-1 follows
Description of "Figure 3-1 Overall Application Architecture with ADF Model"

Core Benefits of ADF Model

Tight integration with JDeveloper tools simplifies building the model layer of the Fusion web application and supports binding the user interface with data from the business services.

ADF Model has features that benefit both UI developers and developers of application logic.

For UI developers, the core benefits are:

  • Using JDeveloper, drag-and-drop creation of databound components and configuration of bindings with visual editors.

  • Built-in record navigation and CRUD operations that you can add to your user interface.

  • Standard use of JSF Expression Language (EL) for binding, without needing to understand the implementation of the underlying business services.

  • The ability to bind business services to a variety of user interfaces, including ADF Faces components, JSF and JSP pages, and Microsoft Excel spreadsheets (through ADF Desktop Integration).

For developers who are focused on the application logic and data model, the core benefits are:

  • Not needing to write Java code to handle standard interactions between the business services and the view layer.

  • The ability to declaratively add validation rules, UI hints, default attribute values, and other business logic to your business services as metadata without changing the code in the business services themselves. These declarative enhancements to the data model are propagated to any components that are created from the data control.

  • The ability to work with multiple types of business services in the same way. There are ADF Model data controls for ADF Business Components, EJB session beans, plain Java objects, web services, and other types of services.

Key Concepts of ADF Model

The ADF Model framework supports exposing business services as data collections and method operations to the view and controller layer of the Fusion web application. The framework creates binding objects at application runtime to enable CRUD (create, read, update, delete) operations and method execution.

ADF Model consists of the following central features:

  • data controls, which abstract the implementation technology of a business service by using standard metadata interfaces to describe the service's operations and data collections, including information about the properties, methods, and types involved.

  • declarative bindings, which are used to bind services that are exposed by data controls to UI components.

This section provides an overview of how data controls and declarative bindings work within ADF applications.

Abstraction of the Application's Model Layer

ADF Model builds upon the MVC (model-view-controller) design pattern, in which the code for the application's data model, visual interface, and application flow are all separated. This separation enables multiple types of client displays to work with the same business information. It also helps delineate the responsibilities of the developers working on the different layers of the application.

In a basic MVC architecture, the model layer consists of business services, which in turn interact with the data, as shown in Figure 3-2. With this architecture and without the help of a framework, you would need to code the business services, the controller, and the view components to properly interact with each other.

Figure 3-2 Basic MVC Architecture

Description of Figure 3-2 follows
Description of "Figure 3-2 Basic MVC Architecture"

When you use ADF Model in your application, you save yourself from having to write the Java code that would otherwise be necessary to coordinate the MVC layers. Similarly, the implementation details of the business services are no longer a concern to the UI developer. As shown in Figure 3-3, ADF Model serves as a conduit between the business service and the view and controller parts of the application and presents a standard way of creating bindings between the view and business services.

Figure 3-3 MVC Architecture with ADF Model

Description of Figure 3-3 follows
Description of "Figure 3-3 MVC Architecture with ADF Model "

Declarative Data Binding

In JDeveloper, you can create declarative bindings between data services and UI components by dragging items from the Data Controls panel on to the visual editor for the given UI technology, such as a JSF page. The declarative bindings coordinate between the data controls and the controller and UI layers.

ADF data binding extends JSF data binding by enabling you to bind to ADF data controls declaratively. In a typical JSF application, you would create managed beans and then create EL expression references to them in the JSF page code. However, in an application that uses ADF Model, you can use XML configuration files instead of managed beans. Binding code in these XML files and the EL expressions in the JSF pages are automatically generated when you drag objects from the Data Controls panel on to a page. You can also manually add, delete, and modify bindings in these files.

Key Components of ADF Model

The model layer of the Fusion web application is comprised of ADF data controls that expose the business services as data collections and method operations to the view and controller layers. Such exposure results in declarative data bindings definitions, from which binding objects are created at application runtime to enable CRUD (create, read, update, and delete) operations and method execution.

ADF Model consists of the following components

  • Data controls

  • Declarative bindings

Data Controls

There are different types of data controls, depending on what type of business service you are using. The main types of data controls are:

  • Adapter data controls for common business services such as EJBs, plain Java classes (POJO), SOAP-based web services, and RESTful web services

  • Data controls based on ADF Business Components application modules

Adapter Data Controls

Adapter data controls, as the name implies, act as adapters for non-ADF business services that expose their interfaces in a standard way to the binding layer.

Adapter data controls are available in JDeveloper for the following types of services:

  • EJB session bean

  • Bean (plain Java object)

  • Web service (SOAP-based and REST-based)

  • URL service

  • JMX

There are also placeholder data controls, which enable a UI developer to mock up a data control for purposes of creating databound UI components before the actual business services are available.

Once they have created a data control, developers also have the option of creating data control structure files for the individual services that are encompassed by the data control in order to configure them with declarative metadata. The configuration possibilities in these structure files mirror the type of declarative configuration that you can do with ADF Business Components view objects.

The following are some of the types of metadata that can be added to adapter data controls:

  • Default values of attributes.

  • Transient attributes.

  • UI hints for attributes.

  • Validation rules (including templates for comparison operations, range, length, and the opportunity to write rules based on regular or Groovy expressions).

  • Named criteria, which can be used to create UI search components based on pre-selected partial search criteria. Named criteria are only available for JPA-based adapter data controls.

  • List-of-values (LOV) components, which enable UI developers to create list components that are populated by a given table in the data source.

When you create an adapter data control, a data control definition file with the name DataControls.dcx is created. If you subsequently add declarative metadata for objects represented by the data control, XML files are generated to hold that metadata.

ADF Business Components

ADF Business Components services are directly integrated with ADF Model. A data control in an ADF Business Components application derives from the data model that you set in one or more application modules. View objects encapsulated by the application module represent the business services and can be configured both declaratively and programmatically. The types of declarative metadata available for a view object include all of the types of metadata available for adapter data controls as well as other metadata specific to view objects.

For more information on application modules and view objects, see Key Components of ADF Business Components.

Declarative Bindings

Declarative bindings provide a way to call from the view layer into the model layer using EL expressions or Java code.

The following are the three categories of bindings:

  • value bindings, which are used by UI components to display data. There are sub-types of value binding objects for trees, lists, and other components.

  • action bindings, which are used to bind buttons and links to service methods and operations.

  • executable bindings, which include iterator bindings and which generally concern background tasks, such as managing queries and row currency.

These binding objects are defined in page definition files, which are created and updated automatically when you use the Data Controls panel to create databound components. By default, a generated page definition file name takes the name of its corresponding web page, appends pageDef, and takes the xml extension. There is one page definition file for each page.

The binding objects for each page reference data control objects to provide the UI components with data. At runtime they are instantiated in a binding container. A page can access its corresponding binding container using expressions based on the EL namespace bindings. Such expressions always evaluate to the binding container for the current page. A typical expression takes the form #{bindings.BindingObject.propertyName} where BindingObject refers to an object or attribute defined in the page definition file and propertyName refers to a standard ADF binding property. For example, #{bindings.Phone.inputValue} would return the value of the Phone attribute.

Together, all of an application's binding containers and their references to data controls form the application's binding context. This binding context is represented at design time by the DataBindings.cpx file, which is located in an application's UI project.

ADF Model at Runtime

The ADF Model framework creates binding objects at application runtime to enable CRUD (create, read, update, delete) operations and method execution on business services in the Fusion web application.

At runtime, the ADF Model layer does the following:

  • Reads the DataBindings.cpx file to set up the binding context based on the listed page definition files and the data controls that they are mapped to as depicted in Figure 3-4.

  • Instantiates the bindings in order to create the two-way connection between the user interface and the business services.

Figure 3-4 Files Used in Data Binding

Description of Figure 3-4 follows
Description of "Figure 3-4 Files Used in Data Binding"

Figure 3-5 depicts the connection between the data controls, declarative bindings, and view layer.

Figure 3-5 Binding Data Sources to UI Components Using ADF Model

Description of Figure 3-5 follows
Description of "Figure 3-5 Binding Data Sources to UI Components Using ADF Model"

Overview of the ADF Model Process Flow

Creating declarative data bindings for the user interface components of the Fusion web application that you develop with Oracle ADF follows a step-by-step process that is supported by JDeveloper tools.

This section describes the process flow for working with ADF Model. The process differs depending on whether you are using ADF Business Components or other types of data controls.

Development Steps for Using ADF Model with ADF Business Components

Using ADF Model with ADF Business Components simply consists of building the business components. For more information, see Overview of the ADF Business Components Process Flow.

Development Steps for Using ADF Model with non-ADF Business Services

Using ADF Model with non-ADF business services consists of the following basic steps:

  1. In JDeveloper, create an application workspace for the application.

  2. In the application workspace, create or import the business services on which the data control will be based.

    These services might be EJB session facades, plain Java objects (POJOs), web services, or other types of service for which you have a data control. To create the services, you might also need to a connection to a database, URL, or a schema.

  3. Using a wizard that is available in JDeveloper's New Gallery, create data controls for the business services.

  4. Optionally, use JDeveloper's visual editors to declaratively specify business rules for the services that are encapsulated by the data controls.

  5. Optionally, for JPA-based data controls, use the ADF Model Tester to test the business services.

  6. Using the Data Controls panel and various binding editors, create databound components in the view layer.

Learning More About ADF Model

When you are ready to configure data bindings in the model layer of the Fusion web application, you may consult documentation dedicated to these tasks in the Oracle Fusion Middleware documentation library.

The following resources provide detailed information about using ADF Model in applications: