ADF Business Components - Part1

ADF Business Components [Fundamentals] - My own understanding and View

Introduction:

ADF BC is a Java and XML based framework for developing the following :

• Business logic, including validation and default logic Queries 
• Transaction handling Data access              

It does not create a user interface, but is a pure encapsulation of business logic that communicates with a separate client application, which handles user interaction. Using ADF BC is the simplest way to design data-aware applications with JDeveloper. 

The advantage of ADF BC over UI-enforced business logic is re-usability. For example, a single ADF BC layer can provide the business logic for all a company's needs. The business components can be used again and again, with multiple interfaces (a time saver). By maintaining a cache of data in memory, ADF BC reduces the number of database trips required by an application resulting in improved performance and scalability. ADF BC allows the business logic to be written in Java, which saves the trouble of integrating a Java GUI or JSP application with business logic written in PL/SQL code.Removing the business logic out of the database keeps the database from handling anything but data, which increases an application's modularity and efficiency.

There are also advantages to implementing some business logic directly in the database (more robust) since it will be enforced even in a SQL*Plus session. Business logic implemented in the ADF BC layer is only enforced in applications using that layer, but increases performance.

ADF BC also has the advantage of being "deployment-configuration independent". A single ADF BC layer can be deployed as local Java classes or as an Enterprise JavaBean (EJB), with no rewriting of code necessary. You can concentrate on the business logic of your application instead of its deployment requirements.

ADF BC components (whether deployed to a J2EE web module with JSP pages or as an EJB) are fully J2EE-compliant. The ADF BC framework automatically implements the J2EE BluePrints design patterns suggested by Sun Microsystems so you do not need to worry about them.

Components:

Entity objects, view objects, and application modules each have two parts: a Java class file and an XML file. The files have different purposes.  ADF BC is a framework, this means that much of its functionality is contained in a set of libraries. ADF BC classes extend (subclass) the base classes provided by these libraries to provide complex business logic, which requires the procedural power of Java to implement. 

This allows you (if needed) to:

1. Easily write code to implement complex business rules inside your entity object Java classes

2. Code complex query logic in your view object classes

3. Code complex transaction handling in your application module classes.

These components represent features of the database: tables and views, constraints, and relationships. They are the most reusable business components because they can be used by any application that needs to access the same data.

Business Components

These components represent the database tables. [reusable components]

There are three kinds of business domain components:

•    EO

•    Associations

•    Domains

1.Entity Object:
------------------------

An entity object definition usually represents a database table or database view, but it can also be used to represent EJB entity beans. It acts as a representation of the table or database and handles all of the business rules for that table or view including validation, defaulting, and anything else that happens when a row is created, deleted, or changed. The power of  business component is its interface with the database used by an application.

The ADF BC layer represents the database table as an entity object. An entity object has entity attributes that represent the table columns (mapping may not always be one-to-one).


The types of the properties are Java classes that correspond to the SQL types of the columns.

The equivalent entity object attributes and equivalent Java Type:

Entity Object related files in ADF:

•  The definition XML file contains metadata describing the entity object, its attributes, and the table upon which it is based, as well as declarative code. 
• A Java file is created to implement the entity object.

Relationships within Components:

2.Associations:
---------------------

The relationships between entity objects are called associations. An association matches one or more attributes of a "source" entity object with one or more attributes of a "destination" entity object. Associations are stored in an XML file. Similar to a foreign key constraint that matches one or more columns of a child table with one or more columns of a parent table. 

3.Domains:
------------------

Domains are special java types used by ADF BC as the types for many entity object and view object attributes. In the coverage of entity objects earlier, a class that implements the Departments entity object has some entity attributes of type oracle.jbo.domain.Number. The entity attributes of an entity object Java class are objects, not primitive Java types such as int.

Database columns of SQL datatype VARCHAR2 have the Java class java.lang.String. For other SQL types (NUMBER, etc.), ADF BC provides domains to wrap the SQL datatype. Domains like oracle.jbo.domain.Number are basically object wrappers for scalar types.
JDeveloper will automatically create a domain if you base an entity object on a table with an Oracle object type column in it. This domain represents the Oracle object type, giving you Java wrappers for each of the object type's fields and methods. You can also create your own domains.

Presentation Data Model Components:

Business components that collect data and present it to the view and controller through the ADF model layer. They are not reusable as business domain components because their design is based on the data needs of a particular client application.They are still independent of a user interface.

• There are three kinds of data model components:
• View object definitions
• View link definitions
• Application module definitions

1. View Object Definitions:

------------------------------------
Generally you should not present all of the information stored in a database object (entity object) in one application. You may also want/need data taken from more than one database object. 

SQL provides the queries necessary to select exactly the data you need from one or more tables. This is why ADF BC has view object definitions, which correspond to SQL queries. A view object definition actually stores a SQL query



This view object would have the following view attributes:




The above view attributes may be (but not required to be) associated with attributes from entity objects. View objects have two parts:

• A Java class (like <CustomName>ViewImpl.java) – This class handles the complex logic or the queries, controlling the client's access to the data.
• An XML file (like <CustomName>View.xml) – This stores information        about the query and its relationships to entity objects.

1.View Link Definitions:
---------------------------------
A View link represents a relationship between the query result sets of two view objects. It associates one or more attributes of one view object with one or more attributes of another.

A view object, DepartmentsView, containing the following query:



Another view object, EmployeesView, containing the following query:



A view link, DeptEmpFkLink, that associated the DepartmentId attribute of EmployeesView with the DepartmentId attribute of DepartmentsView. 

DeptEmpFkLink represents a master-detail relationship between the query result sets of DepartmentsView and EmployeesView.View links between view objects can be (but do not have to be) based on associations between underlying entity objects. A view link is represented in an XML file.

Application Module Definitions

An application module is a container for view usages (instances of view objects). It lists all of the view usages your application requires and specifies how they are related by view links. These relationshipscan be represented by a tree (application module's data model). An application module definition is a template for application module instances, which are individual copies of the data model used by particular instances of the application. Each instance represents an individual database transaction.

For example, an application module might contain usage of DepartmentsView, called AllDepartments, and a usage of EmployeesView, called DepartmentEmployees, linked by an instance of EmpDeptFkLink, called DepartmentToEmployees. 

Application model using the data model as follows :

Using this model, the two view usages are tied together by a link representing a master-detail relationship between them (EmpDeptFkLink). Using this application module, your client application could select a row in AllDepartments, and the ADF BC framework would immediately synchronize DepartmentEmployees so that it would only return employees from the selected department. 

Your application module could contain a usage of DepartmentsView and a usage of EmployeesView without using EmpDeptFkLink, as in the following data model:

This module provides usages of the same two view objects, but the view usages are linked. Your client application could select rows in AllDepartments and Allmployees usages independently. 

You can even include two instances of EmployeesView in an application module: one a detail of an instance of DepartmentsView and one independent as in the data model below: 

With this application module, a client application could select rows in DepartmentEmployees and have them automatically synchronized with AllDepartments and could also select rows in AllEmployees independently. 

Creating Components:

Let's learn the following topics:

1. Create entity object definitions from tables
2. Edit entity object definitions to delete entity attributes representing database columns you do not need
3. Add transient entity attributes to represent calculated fields
4. Represent PRIMARY KEY and NOT NULL constraints.

Create entity object definitions from tables

      -       An entity object is the representation of a database table or view

      -       An entity object has one or more entity attributes representing columns in a table 

               or view.

      -       The Java types of the entity attributes are classes corresponding to the SQL types of                  the columns, and some entity attributes are mapped to a particular Java class called                 "domains".

      -       Associated with each entity object is a Java file with code logic and an XML file with                the definition of the entity, including its attributes. 

Points to remember:

• Good to have one to one mapping between table columns & entity attributes.
• Consider to delete attributes which is no use or the column against in the table is            not participated in the business logic.
• Transient attributes are attributes you calculate or set on a particular row that are needed for the duration of the transaction, but are not stored in the database.
• Always, entity attributes sync with tables columns. If any of the column deleted or added,  you have to do the same change within entity object attributes.
• Please make sure that entity object has proper java data type against each column of the table. Please refer online docs to map SQL Datatypes to Acceptable Java Types.
• If you want to create ADF BC objects that use a non-Oracle database, you will have to use a separate type map to associate datatypes with Java types – either JDeveloper's "Java" type map or a type map you create.

Constraints:

     NOT NULL constraints:

When an entity object from a table is created, JDeveloper determines whether any of the columns in the table has a primary key or NOT NULL constraint. If either is has been defined, JDeveloper automatically generates the corresponding XML code.

The reason ADF BC allows NOT NULL constraints in entity objects is performance. ADF BC saves up user changes until a post or commit is requested. By representing the NOT NULL constraints in the entity objects (instead of the database) ADF BC can verify the constraints are satisfied without making a round trip to the database. 

     PRIMARY KEY constraints

The reason ADF BC represents the PRIMAY KEY constraint in entity objects is different. ADF BC uses entity attributes tagged as part of the primary key to look up particular instances of the entity object class. Without primary key attributes, ADF BC has no way of distinguishing between different entity instances.

If you want to use ADF BC to access a non-Oracle database, you must ensure that all of your tables have primary keys.

If the table has no primary key, you may face some issues within the application because there is no way to differentiate every entity instance.

    Additional constraints

• You may want to define constraints in an entity that do not correspond to any database constraint, if the following conditions hold: 1) You do not change your database tables, and a new constraint. 2) You need a constraint but you do not have permission to perform DDL operations to  change the table. 3) The constraint applies only to your applications; other applications using the same tables do not need it. You need a constraint but you do not have permission to perform DDL operations to change the table.

• You also might want to represent a column constraint that has been added to a database table since you created the corresponding entity object. This is done as follows:

1. On the entity object node select Edit from the right-click menu.
2. Select the Attribute Settings node.
3. Choose an attribute from the Select Attribute dropdown.
4. To make the attribute NOT NULL, check the Mandatory checkbox.
5. To make the attribute part of the primary key, check the Primary Key checkbox. If this is checked for multiple attributes, they will function as a multi-part key.

Synchronizing Entity Objects with the Database

In addition to manually adding and dropping attributes or constraints, JDeveloper can be used to automatically synchronize some or all of the entity objects with the Database.

On the ADF BC package node in the Navigator, select Synchronize with Database from the right-click menu and use this dialog to select any desired updates to the ADF BC tier.

Representing Relationships Between Tables 

1. Foreign key relationships between tables are represented by associations between entity objects. JD will create an association corresponding to each foreign key constraint that occurs between tables you select. You may want to define associations that do not correspond to any foreign key constraint, if one of the following conditions hold:
2. You need a relationship but do not have permission to perform DDL operations to change the table
3. The relationship applies only to your applications; other applications using the same tables do not need it
4. The relationship involves transient entity attributes
5. The relationship is a many-to-many relationship (explained next).

 Association Cardinality:

The most common kind of relationship between tables is the one represented by a foreign key: a row in the master table corresponds to any number of rows from a detail table. This is a one-to-many relationship shown below:

        Another is a one-to-one relationship illustrated below: 

The most complex is a many-to-many relationship where any number of rows from one table can be related to any number of rows from the detail table. This relationship is illustrated below:

Creating a many-to-many association is more complex because it makes use of a third table called an intersection table. An intersection table contains two foreign keys. One matches up with the primary key of one table and the other with the primary key of the other table as illustrated below: 

Two 1-to-many relationships are created. You can think as these two one-to-many relationships as representing a single many-to-many relationship, which relates one row from EMPLOYEES and JOBS if they share a JOB_HISTORY detail as shown below:

Consider two different sorts of foreign key relationships:

 - The relationship between employees and the departments that employ them.

 - The relationship between line items in a purchase order and the order itself.

Most employees are in a department, but an employee is not, strictly speaking, part of a department. Employees exist independently of their departments; a company can eliminate a department without eliminating its members. By contrast, it makes no sense to delete a purchase order without deleting its line items. An association is like the one between line items and purchase orders, where the detail is part of the master, is called a composition. You cannot delete a master in a composition without deleting all its details. 

If the Business Components Package Wizard detects that a database foreign key has ON DELETE CLAUSE set, it automatically creates the association as a composition. This can also be done on the Association Properties page of the Association 

Optimize for Database Cascade Delete – prevents the application from issuing explicit DML commands to delete detail rows when the master row is deleted.  If the database is doing this automatically (because ON DELETE CASCADE is set), efficiency is improved.

Implement Cascade Delete  - deletes detail entity object instances when the master is deleted. This checkbox is checked automatically. If it is unchecked, deleting a master that still has details with throw an exception.

Cascade Update Key Attributes – makes destination attributes stay synchronized with source attributes. 

         Representing Oracle Data Types: 

ADF BC automatically associates standard column types with Java classes (like java.lang.String) or built-in domains (such as oracle.jbo.domain.Number). Some columns many be custom Oracle object types. Custom Oracle object types are represented as domains. When you create an entity object based on a table with an Oracle object type column, JDeveloper automatically creates a custom domain and maps the column to an entity attribute with that domain as its Java type. 

Consider an Oracle object type called ADDRESS_TYP with the following definition:

You could create a table called CUSTOMERS that uses this object type as follows:

If you create an entity object from the table, it will have attributes called CustomerId, CustFirstName, CustLastName, and CustAddress, and  automatically a domain, AddressTyp, with attributes StreetAddress, PostalCode, City, StateProvince, and CountryId.

On the other hand, a table called ADDRESSES can be created as follows: 

If you then create an entity object from ADDRESSES, it will have attributes called StreetAddress, PostalCode, City, StateProvince, and CountryId, and NO domain will be created.