This topic is specifically for developers who are familiar with creating client-server applications using a rapid application development (RAD) tool such as Oracle Forms. In typical two- and three-tier client-server applications, most of the development work is focused on the client forms. Therefore this type of application will be referred to as forms-based for the remainder of this topic. Although Oracle Forms in particular will be referenced throughout, users familiar with other RAD tools, such as Visual Basic and PowerBuilder, might find much of this information useful.
Before starting to learn about Oracle ADF Business Components, it might be helpful to review what you are assumed to know and not know.
As a forms-based application developer you probably know how to:
As someone new to Oracle ADF Business Components, you might not know how to:
Much of what you know will translate easily, and learning the rest only requires proper orientation. What you know about developing in a forms-based tool will provide a good base from which to learn Oracle ADF Business Components.
Both Forms and Oracle ADF Business Components are application frameworks. A framework is responsible for doing all the "application plumbing": interacting with the database, commit processing, enforcing validation at event points, etc. The framework allows the developer to focus on the business problem, not the background details.
The main difference between the two frameworks is that Oracle ADF Business Components separates the UI from the data access. You will see later how this separation facilitates better access and reuse of the components.
The Forms runtime engine, or Forms Server, runs the data in a Forms definition file. Typically a Forms definition consists of both UI objects (windows and canvases) and data blocks. A Forms definition is made up of two parts: the metadata and the implementation code. The metadata describes the blocks, items, windows, canvases, etc. The user-written implementation code is a combination of triggers and PL/SQL packages, procedures, and functions. Collectively, these parts are stored in the Forms .fmb file.
From a high level, Oracle ADF Business Components and Forms have similar architectures. Like Forms, metadata is set apart from implementation code. However, where the Forms definition file could be very large and might contain many data blocks, Oracle ADF Business Components divides the parts into smaller modular pieces called business components . Business components are a pairing of a Java class and an XML metadata file. These finer-grained components make for better reuse and easier customization.
Another difference in the architectures is the separation of the implementation code into two pieces: the compiled Java code, and the client (presentation) code.
Application development in both frameworks is more closely examined later in this topic, and that will do more to illustrate these differences. But before that you need to know what the business components are and what they do.
The easiest way to understand that business compoents are is to relate them to Froms constructs you already know. Indeed, you will find that many Forms objects have analogous counterparts in the business components architecture. The differences are a result of the way business components separate the data from the user interface. For example,
A Forms data block has two primary responsibilities:
A data block allows you to work with rows within a database, directly from the user interface. Operators can use data blocks to automatically query, update, insert, and delete rows within that table or view.
In Oracle ADF Business Components this functionality is split between two different objects, view objects and entity objects. View objects are the objects responsible for querying data, while entity objects are responsible for modifying data in the database. Splitting the functionality into two objects allows querying data in many different ways while using the same validation and data manipulation logic.
Each data block in a form represents some view of the available data. The form may contain a subset of the available values, have certain fields hidden, apply only to a specific group of people, etc. For example, this form could be called Employees, and only show their names, addresses, and phone numbers. You might have a similar form accessible by managers that shows a different view of data, for example their salary would be displayed.
The way Oracle ADF Business Components represents this selective view of data is through a view object. View objects are reusable components that contain a SQL query. This query can be based on one or many database tables. In your business components application, each unique view of data will be represented by a single view object. You will have as many view objects you need to represent the data in your "forms".
When you think of view objects, think of them as being half of a data block, the part responsible for querying data.
Like Forms data blocks, entity objects are usually based on database tables or views. Think of entity objects as classes that represent your database tables.
The representation of tables in your forms-based application correspond one-to-one with entity objects in a business components application. For example, if you have an Orders form that modifies information in the Salesperson, Customer, and Item tables, you would have three entity objects that represent those tables.
Entity objects are not only used for storing data, but are also used to validate data. Entity object validation is done at a higher level than database triggers, and this is a common source of confusion. While you can use triggers with Oracle ADF Business Components, it makes more sense to attach the validation to the entities, as you can then apply validation to unposted data.
The master-detail functionality performed by Forms relations is provided by view links. View links define the relationship between two view objects. To define a view link you specify which view object is the master, which is the detail, and specify which columns they are related by.
In your forms-based applications, each form was probably created to do a particular task; a unit of work within a single transaction. For example, you might have created an Order form who's task it was to do everything required to place an order: first to take the information from the order, then to make sure the information there was valid, and finally to post changes to the database.
In Oracle ADF Business Components, every task is associated one-to-one with an application module. In the above example, your Order form would be represented by a single application module. Unlike a form, there is no user-interface component to an application module, it is simply a model of the data and how they relate to each other. With a user interface "front end" plugged into the application module, the functionality is the same as a form.
A form is a container for data blocks, and as such might have displayed data from multiple views of data. For example, an Order form could have contained data blocks based on the Customers, Items, and Salesperson tables. Likewise, if your task requires the use of more than one view of data, your application module will contain more than one view object. An application module also contains view links, which describe the relationship between the view objects.
The way that view objects and view links are related to each other is not coordinated by the framework, as they are with data blocks and relations. Instead, the queries (view objects) and relations (view links) are described by a data model.
If you are familiar with Oracle Reports, you know that Forms and Reports are conceptually different in the way that they deal with the data model. In Forms, there is an implicit data model described by the data blocks and relations. Oracle Reports separates the queries and relationships, allowing you to define the data model explicitly; you can build a data model from queries and draw links between the queries.
Just like Reports, the data model in Oracle ADF Business Components is explicit, but is described by in an application module by view objects and view links. Based upon those similarities, one way of looking at Oracle ADF Business Components is that it provides the separation of data provided by Reports with the data manipulation provided by Forms.
When two database tables are linked by a key, the business component representation is an association object. Associations allow you to retrieve data from related tables.
Associations are created automatically by the business components framework when database foreign key constraints are detected in the database. You can also create associations directly using the business component wizards. View links can be easily created using the underlying associations. This makes it very easy to get related information and show it on the UI.
Before you go on, it might be helpful to recap what you have learned by reviewing the the role of business components and how they relate to Forms constructs:
In both Forms and Oracle ADF Business Components, you start by creating a framework-level container. In Forms this is called a Form Module, while in Oracle ADF Business Components this is called a Project. Next, the objects that will communicate with the database are created. For Forms this is the data block, for Oracle ADF Business Components, these are the business components. Up to this point, application development is quite similar.
The first difference you will notice about Oracle ADF Business Components is that the data elements are not tied to the UI in the same way that they are in Forms. In Oracle ADF Business Components, your UI components can take information from any number of underlying database tables. While you can start laying out UI elements immediately in Forms, in Oracle ADF Business Components you create your UI separately.
Another difference that you'll notice, and one that is related to separating the business logic from the UI, is in the way business rules are enforced.
Suppose you want to create an application that allows employees to view and change their data. Among the business rules you needed to implement could be the following:
In a forms-based application, the client forms enforce the business rules through UI controls such as lists and option buttons. Validation is enforced through UI events, such as a text field losing focus, or a database event such as a new row being inserted.
The three conditions that need to be validated might be done in the following manner:
To enforce the same three business rules in Oracle ADF Business Components, you would not code the validation in the client or on the database. Instead, validation code goes on the business logic tier (business logic tier).
Now suppose you had to create another similar form, this one to be accessed by managers and additionally showing salary information. In a typical RAD environment, this means creating a new UI, attaching validation code to the various fields, etc.
In Oracle ADF Business Components, you can reuse all the validation without re-coding any of it. Since all the validation is attached to the entity objects, every time you use the entities the validation comes with it. This is a drastic improvement in reusability. Also, if the business rules change, for example, the passwords are now required to be 8 characters, you can edit the entity objects to reflect that change and all views of data are simultaneously updated. The reuse of business rules is one key advantage of Oracle ADF Business Components. Another is the flexibility of the framework.
One frustration for Forms developers is that it is very hard to change the way the Forms framework operates. If you want navigation or validation to work in a special way, you have to short-circuit the framework by writing triggers. Indeed, developers can spend a great deal of time writing triggers to deconstruct the default way the framework operates so that they can customize behavior for their application.
Oracle ADF Business Components allows you to extend new business components from base business component classes, or even substitute new business components for the existing ones. This means that an enterprise application can be modified after it has been delivered, without ever changing the original source code.
In Forms, when you are working with a master-detail form and you want to make changes to another form, you must first commit the changes to the form you are working on. This is a limitation for the user, as they might be forced to commit changes before they are through with the form. The user interface can be misleading in this way, because it allows you to look at the forms as if they are independent. For working on forms that are dependent on each other, this model is very hard to work with.
Also, if the information in another form was necessary to complete the task in the form the user was working on, the user would need to do a query over the other forms to find that information. After seeing multiple query results from the search, they would go to a detail screen that show more info, and gather their information there.
In Oracle ADF Business Components the user can work on multiple forms at the same time. A change in one record propogates to multiple forms. The user can query back and forth between objects and make whatever modifications they desire. If the task on one form is related to other forms, the interaction between forms is seamless. Finally, the user can commit the changes when they are through with their work, not when the framework forces them to.
Although Oracle ADF Business Components allows users to work on multiple forms at the same time, this feature exposes a limitation, which is the inability for the framework to clear a block (or record) at the form level.
In Forms, CLEAR_BLOCK (or CLEAR_RECORD) allows you to clear all the changes made in a single block and start over again. You can't do this in Oracle ADF Business Components because the view object you are trying to clear may have made changes to other view objects and these changes are not kept track of by the individual view objects. This management of data is done at the application module level, which is why you can work on multiple forms at the same time. If you want the ability to clear data at the form level, it must be managed in the UI, not in the framework.
Forms and Oracle ADF Business Components are both application frameworks, and from a high level, they share similar architectures and concepts. However, Oracle ADF Business Components is a finer-grained solution that separates the metadata from the UI. The benefits of this are many, including easily reusable business logic, a customizable framework, a client-independent business logic tier, and caching of data at the application level.
Introducing Oracle ADF Business Components
Copyright © 1997, 2004, Oracle. All rights reserved.