Chapter 8 Introducing ADF Business Components

translatoryazooInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 4 χρόνια και 1 μέρα)

89 εμφανίσεις

1

Chapter 8

Introducing ADF Business
Components

2

Introducing ADF Business Components


ADF BC

is a Java and XML based framework for developing:



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. This chapter presents an overview of ADF BC by
describing its components and uses.

3

Why Use ADF BC?


The advantage of ADF BC over UI
-
enforced business logic is reusability.
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).

4

Advantages of ADF BC

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.

5

Advantages of ADF BC
(continued)

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.


There is a trade
-
off between robustness and performance.


Therefore, the most critical business logic should be implemented in the
database or redundantly in both the database and a ADF BC layer. The
remainder of the business logic can be implemented in the ADF BC
layer.

6

Advantages of ADF BC
(continued)

ADF BC provides four ready
-
made architectures for business
component clients:



JClient
, an architecture for creating Java GUIs (useful for intensive
data
-
entry applications requiring high interactivity).



Thin JSP clients

are useful for web
-
based applications where a
thin client is more important than very high interactivity, such as
self
-
service and e
-
commerce applications.



XSQL clients
, which generate XML for either flexible display with
a style sheet or loose coupling between applications.



UIX
, a framework
-
based architecture for developing web
applications.

7

Advantages of ADF BC
(continued)

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.

8

Business Components, Java, and XML


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:



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



Code complex query logic in your view object classes



Code complex transaction handling in your application module
classes.

9

Business Components, Java, and XML


The base classes in the ADF BC framework are programmed to work
with XML files. Some business logic is common and simple and can be
handled with a line or two of declarative XML. Instead of writing a
procedure to implement this sort of business logic, you can just declare
that an entity attribute, for example, must obey a particular validation
rule. The base entity object class (and by inheritance, your custom Java
class) can automatically read the XML file to enforce the rule.
JDeveloper has wizards that write and edit the XML files for you.


The ADF BC framework uses XML files to store static definitions such
as the structure of a database table or query. Its base classes can obtain
the structure of particular business components by parsing the XML.

This can have performance advantages. For example, an entity object
dose not need to query the database at runtime for structural information
about the table it represents.

10

ADF Business Component Groups


ADF BC components are divided into two groups:


Business domain components



Data model components

11

Business Domain Components


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.


There are three kinds of business domain components:



Entity Object definitions



Associations



Domains

12

Entity Object Definitions


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 ADF BC 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.

13

Entity Object Definitions


Example:
DEPARTMENTS

table





Entity objects for the above table may have the following


entity attributes:


14

Entity Object Definitions


Java does not directly support SQL datatypes, but each SQL datatype can
be mapped to a Java type. Some Java types are classes in
java.lang

and
others in the package
oracle.jbo.domain

(discussed later).

Entity objects have two parts:


1.
A

Java class

(like DepartmentsImpl.java)


This contains the

procedural code to implement the entity object.


2.
An
XML file

(like Departments.xml)


This includes metadata

describing the entity object, its attributes, and the table upon

which it is based, as well as declarative code.

15

ADF BC Relationships (page 228)

16

Associations

Like tables, entity objects are often related to one another. 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.


This is like a foreign key constraint that matches one or more columns
of a child table with one or more columns of a parent table.


Associations are stored in an XML file.

17

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
.

18

Data Model Components



They are 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

19

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.

20

View Object Definitions

(continued)

A view object definition has
view attributes

(like entity objects have
entity attributes) that correspond the columns of a query result. For
example, consider the view object for the following query:

SELECT Departments.DEPARTMENT_ID,



Departments.DEPARTMENT_NAME,



Employees.EMPLOYEE_ID,



Employees.FIRST_NAME,



Employees.LAST_NAME

FROM DEPARTMENTS Departments, EMPLOYEES Employees

WHERE Departments.MANAGER_ID=Employees.EMPLOYEE_ID;

This view object would have the following view attributes:


21

View Object Definitions

(continued)

The above view attributes may be (but not required to be) associated
with attributes from entity objects.



View objects have two parts:


1.
A

Java class

(like ManagerViewImpl.java)


This class handles
the complex logic or the queries, controlling the client's access to
the data.


2.
An
XML file

(like ManagerView.xml)


This stores information
about the query and its relationships to entity objects.

22

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.

23

View Link Definitions

(continued)

For example:


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
.

SELECT Departments.DEPARTMENT_ID,


Departments.DEPARTMENT_NAME

FROM DEPARTMENTS Departments


SELECT Employees.EMPLOYEE_ID,


Employees.FIRST_NAME,


Employees.LAST_NAME,


Employees.DEPARTMENT_ID,

FROM EMPLOYEES Employees

24

View Link Definitions

(continued)

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 (more on this in later chapters).

25

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 relationships

can be represented by a tree (application module's
data model
).


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
.

26

Application Module Definitions

(continued)

This uses the following data model:

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.

27

Application Module Definitions

(continued)

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.

28

Application Module Definitions

(continued)

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.

29

Application Module Definitions

(continued)

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.

30

The hands
-
on practice beginning on page
234 examines a default ADF BC layer.


ENJOY!