| Oracle® Application Development Framework Developer's Guide For Forms/4GL Developers 10g (10.1.3.1.0) Part Number B25947-01 |
|
|
View PDF |
| Oracle® Application Development Framework Developer's Guide For Forms/4GL Developers 10g (10.1.3.1.0) Part Number B25947-01 |
|
|
View PDF |
ADF Business Components provides components that implement functionality similar to what you are used to in the enterprise 4GL tools you have used prior to embarking on J2EE development. This section will assist you in understanding how the key components in ADF Business Components map conceptually to the ones you have used in other 4GL tools.
ADF Business Components implements all of the data-centric aspects of the familiar Oracle Forms runtime functionality in a way that they can be used with any kind of user interface. In Oracle Forms, each form contains both visual objects like canvases, windows, alerts, and LOVs, as well as non-visual objects like data blocks, relations, and record groups. Individual data block items have both visual properties like Foreground Color and Bevel as well as non-visual properties like Data Type and Maximum Length. Even the different event-handling triggers that Forms defines fall into visual and non-visual categories. For example, it's clear that triggers like WHEN-BUTTON-PRESSED and WHEN-MOUSE-CLICKED are visual in nature, relating to the front-end UI, while triggers like WHEN-VALIDATE-ITEM and ON-INSERT are more related to the back-end data processing. While merging visual and non-visual aspects definitely simplifies the learning curve, the flip side is that it can complicate reuse. With a cleaner separation of UI-related and data-related elements, it would be easier to redesign the user interface without disturbing back-end business logic and easier to repurpose back-end business logic in multiple different forms.
In order to imagine this separation of UI and data, consider lopping a form as you know it today in half, keeping only its non-visual, data-related aspects. What's left would be a container of data blocks, relations, and record groups. This container would continue to provide a database connection for the data blocks to share and be responsible for coordinating transaction commits or rollbacks. Of course, you could still use the non-visual validation and transactional triggers to augment or change the default data-processing behavior as well. This non-visual object your considering is a kind of a "smart data model" or a generic application module, with data and business logic, but no user interface elements. The goal of separating this application module from anything visual is to allow any kind of user interface you need in the future to use it as a data service.
Focus a moment on the role the data blocks would play in this application module. They would query rows of data from the database using SQL, coordinate master/detail relationships with other data blocks, validate user data entry with WHEN-VALIDATE-RECORD and WHEN-VALIDATE-ITEM triggers, and communicate valid user changes back to the database with INSERT, UPDATE, and DELETE statements when you commit the data service's transaction.
Experience tells you that you need to filter, join, order, and group data for your end-users in many different ways depending on the task at hand. On the other hand, the validation rules that you apply to your business domain data remain basically the same over time. Given these observations, it would be genuinely useful to write business entity validation exactly once, and leverage it consistently anywhere that data is manipulated by users in your applications.
Enabling this flexibility requires further "factoring" of your data block functionality. You need one kind of "SQL query" object to represent each of the many different views of data your application requires, and another kind of "business entity" object that will enforce business rules and communicate changes to your base table in a consistent way. By splitting things again like this, you can have multiple different "view objects" working with the same underlying "entity object" when their SQL queries present the same business data.
Oracle ADF breathes life into the UI/data split you imagined above by providing ready-to-use Java components that implement the Forms-inspired functionality you're familiar with in the Java world, with responsibilities divided along the cleanly-separated functional lines you just hypothesized.
The ApplicationModule component is the "data half of the form" you considered above. It's a smart data service containing a data model of master/detail-related queries that your client interface needs to work with. It also provides a transaction and database connection used by the components it contains. It can contain form-level procedures and functions called service methods, that are encapsulated within the service implementation. You can decide which of these procedures and functions should be private and which ones should be public.
The EntityObject implements the "validation and database changes half" of the data block functionality from above. In the Forms runtime, this duty is performed by the record manager. It is responsible for keeping track of which of the rows in a data block have changed, for firing the validation triggers in a data block and its data items, and for coordinating the saving of changes to the database. This is exactly what an entity object does for you. Related to an underlying base table, it's a component that represents your business domain entity and gives you a single place to encapsulate business logic related to validation, defaulting, and database modification behavior for that business object.
The ViewObject component performs the "data retrieval half" of the data block functionality above. Each view object encapsulates a SQL query, and at runtime each one manages its own query result set. If you connect two or more view objects in master/detail relationships, that coordination is handled automatically. While defining a view object, you can link any of its query columns to underlying entity objects. By capturing this information, the view object and entity object can cooperate automatically for you at runtime to enforce your domain business logic regardless of the "shape" of the business data needed by the user for the task at hand.
If you have developed solutions in the past with PeopleTools, you are familiar with the PeopleTools Component structure. ADF Business Components implement the data access functionality you are familiar with from PeopleTools.
Application Module is a ÒheadlessÓ Component
ADF adheres to an MVC pattern and separates the Model from the View. Pages as you are familiar with in the PeopleTools Component are defined in the view layer, using standard technologies like with JSF and ADF Faces components for web-based applications or Swing for desktop-fidelity client displays.
The ADF Application Module defines the data structure, just like the PeopleTools Component Buffer. By defining master/detail relationships between ADF query components that produce row sets of data, you ensure that any Application Module that works with the data can reuse the natural hierarchy as required, similar to the scroll levels in the Component Buffer.
Similar to the Component Interface you are familiar with, the Application Module is a service object that provides access to standard methods as well as additional developer-defined business logic. In order to present a "headless" data service for a particular user interface, the Component Interface restricts a number of PeopleTools functions that are related to UI interaction. The Application Module is similar to the Component Interface in that it provides a "headless" data service, but in contrast it does not do this by wrapping a restricted view of an existing user interface. Instead, the Application Module is architected to deal exclusively with business logic and data access. Rather than building a Component Interface on top of the Component, with ADF you first build the Application Module service that is independent of user interface, and then build one or more pages on top of this service to accomplish some end-user task in your application.
The Application Module is associated with a Transaction object in the same way that the PeopleTools Component Buffer is. The Application Module also provides a database connection for the components it contains. Any logic you associate today with the transaction as Component PeopleCode, in ADF you would define as logic on the Application Module.
Logic associated with records in the transaction, that today you write as Component Record PeopleCode or Component Record Field PeopleCode, should probably not be defined on the Application Module. ADF has View Objects (see below) that allow for better re-use when the same Record appears in different Components.
Entity Object is a Record Definition
The Entity Object is the mapping to the underlying data structure, just like the PeopleTools Record Definition maps to the underlying table or view. You'll often create one Entity Object for each of the tables that you need to manipulate your application.
Similar to how you declare a set of valid values for fields like 'Customer Status' using PeopleTools' translate values, in ADF you can add declarative validations to the individual Attributes of an Entity Object. Any logic you associate with the record that applies throughout your applications, which today you write as Record PeopleCode or Record Field PeopleCode, can be defined in ADF on the Entity Object.
View Object Queries Data Like a Row Set
Just like a PeopleTools row set, a View Object can be populated by a SQL query. Unlike a row set, a View Object definition can contain business logic.
Any logic, which you would find in Component Record PeopleCode, is a likely candidate to define on the View Object. Component Record PeopleCode is directly tied to the Component, but a View Object can be associated with different Application Modules. While you can use the same Record Definition in many PeopleTools Components, Oracle ADF allows you to reuse the business logic across multiple applications.
The View Object queries data in exactly the "shape" that is useful for the current application. Many View Objects can be built on top of the same Entity Object.
You can define relationships between View Objects to create master-detail structures just like you find them in the scroll levels in the PeopleTools Component.
If you have developed solutions in the past with SiebelTools version 7.0 or earlier, you will find that ADF Business Components implements all of the familiar data access functionality you are familiar with, with numerous enhancements.
Entity Object is a Table Object with Encapsulated Business Logic
Like the Siebel Table object, the ADF Entity Object describes the physical characteristics of a single table, including column names and physical data types. Both objects contain sufficient information to generate the DDL to create the physical tables in the DB. In ADF you define Associations between Entity Objects to reflect the foreign keys present in the underlying tables, and these associations are used automatically join business information in the view object queries used by user interface pages or screens. List of values objects that you reference from data columns today are handled in ADF through a combination of declarative entity validation rules and view object queries. You can also encapsulate other declarative or programmatic business logic with these entity object "table" handlers that is automatically reused in any view of the data you create.
View Object is a Business Component
Like the Siebel Business Component, the ADF View Object describes a logical mapping on top of the underlying physical table representation. They both allow you to provide logical field names, data, and calculated fields that match the needs of the user interface. As with the Business Component, you can define View Objects that join information from various underlying tables. The related ADF View Link is similar to the Siebel Link object and allows you to define master/detail relationships. In ADF, your view object definitions can exploit the full power of the SQL language to shape the data as required by the user interface.
Application Module is a Business Object With Connection and Transaction
The Siebel Business Object lets you define a collection of Business Components. The ADF Application Module performs a similar task, allowing you to create a collection of master/detail View Objects that act as a "data model" for a set of related user interface pages. In addition, the Application Module provides a transaction and database connection context for this group of data views. You can make multiple requests to objects obtained from the Application Module and these participate in the same transaction.
If you have developed solutions in the past with Visual Studio 2003 or 2005, you are familiar with using the ADO.NET framework for data access. ADF Business Components implements all of the data access functionality you are familiar with from ADO.NET, with numerous enhancements.
The ApplicationModule component plays the same role as the ADO.NET DataSet. It is a strongly-typed service component that represents a collection of row sets called view objects, which as described below, are similar to ADO.NET DataTables. The application module works with a related Transaction object to provide the context for queries the SQL queries the view objects execute and the modifications saved to the database by the entity objects, which play the role of the ADO.NET DataAdapter.
The EntityObject is like a strongly-typed ADO.NET DataAdapter. It represents the rows in a particular table and handles the find-by-primary-key, insert, update, delete, and lock operations for those rows. In ADF, you don't have to specify these statements yourself, but you can override them if you need to. The entity object encapsulates validation or other business logic related to attributes or entire rows in the underlying table. This validation is enforced when data is modified and saved by the end-user using any view object query that references the underlying entity object.
The ViewObject component encapsulates a SQL query and manages the set of resulting rows. It can be related to an underlying entity object to automatically coordinate validation and saving of modifications made by the user to those rows. This cooperation between a view object's queried data and an entity objects encapsulated business logic offers all of the benefits of the DataTable with the clean encapsulation of business logic into a layer of business domain objects. Like ADO.NET data tables, you can easily work with a view object's data as XML or have a view object read XML data to automatically insert, update, or delete rows based on the information it contains.
