ADF Business Components in Depth:

The ADF Business Components runtime library handles most business

service functionality, which you can customize declaratively (by changing the
XML files using JDeveloper's RAD tools) or programatically (by extending
library classes).

 Automatically handles Object relational (O/R) mappings and persistence

 Allows you to make complex requests for data retrieval using SQL

 Automatically handles transaction management, including optimistic or

pessimistic locking.

Optimistic and pessimistic locking are two strategies to handle concurrent

access to shared data and prevent conflicts.

 Provides a framework for implementing complex business logic

 Has a powerful caching and data passivation system for increasing the
performance and scalability of applications

ADF Entity Object Definitions:

ADF entity object definitions are (business components that encapsulate the
business model, including data, rules, and persistence behavior, for items
that are used in your application.)

entity objects can represent:

 Elements of the logical structure of the business, such as product lines,

departments, sales, and regions

 Business documents, such as invoices, change orders, and service requests

 Physical items, such as warehouses, employees, and equipment

Entity object definitions map to )single objects in the data source(. In
most cases, these are 1-tables, 2-views, 3-synonyms, or 4-snapshots in
a database. Advanced programmers can base entity objects on objects
from other data sources, such as spreadsheets, XML files, or flat text
files.

An entity object definition is the (template for entity object instances,

which are single Java objects representing individual rows in a
database table). For example, the entity object definition called
"Departments" provides a template for entity object instances that
represent individual rows of the DEPARTMENTS table.

Entity object instances: single Java objects representing individual rows

in a database table.

An entity object definition can have up to four parts:

1. An XML file, which represents the portion of the entity object definition that
can be developed declaratively. Most of the information is that needed for
O/R mapping, but it can also contain simple validation rules,
called validators. For many entity objects, the XML file by itself is
sufficient. EmployeesEO.xml
‫فيها التعاريف االساسية الي بتحتاجها عشان تبني ال اوبجيكت‬.

2. An entity object class, which represents individual entity object instances.

Entity object classes allow you to write complex business logic in Java,
when using XML validators is not sufficient.( Entity object classes extend
the class oracle.jbo.server.EntityImpl.) If you do not need custom
Java business logic, you need not generate an entity object class—ADF
can use oracle.jbo.server.EntityImpl directly to represent rows of the
data source.
‫تستخدم عشان تزيد اشياء زيادة بتحتاجها زي شروط وغيره‬
.( Entity object classes extend the class oracle.jbo.server.EntityImpl.)
‫قصدهم كل الكالسيس بتورث منه‬
 3. An entity definition class, which represents the data source object in its
entirety. )Entity definition classes act as Java wrappers for the XML file(,
so if you need special handling of the metadata (for example, if you need
to change it dynamically), you can add this code in the entity definition
class.
Entity definition classes extend the class oracle.jbo.server.EntityDefImpl. If
you do not need custom handling of your metadata,
you need not generate an entity definition class—
ADF can use oracle.jbo.server.EntityDefImpl directly to wrap the
metadata.
Wrapper classes provide a way to use primitive data types (int, boolean,
etc..) as objects

4. An entity collection class, which represents the cache of rows (instances

of the entity object class) (held in memory for a single user). The vast
majority of developers do not need to generate an entity collection class.
You should do so only if you want to override ADF Business Components'
default caching behavior.

Attributes and Accessors:

When entity objects are based on database objects, columns in the database object
(such as a database table) map to single entity object attributes in the entity object,
although the mapping is not necessarily one-to-one. The definitions of these attributes
reflect the properties of these columns, such as the columns' data types, column
constraints, and precision and scale specifications. When entity objects are based on
objects from other data sources, entity object attributes map to "columns" from those
objects, as defined by the programmer.

There are two sorts of entity object attributes :

1. Persistent attributes are those attributes that do map to data source object
columns.

2. Transient attributes are all those attributes that do not map to data source object
columns. Transient attributes may be derived from information in a database, and
are often used for temporary storage and retrieval.
The values of entity attributes can be read and changed in one of two ways:

 The EntityImpl class provides methods, getAttribute() and setAttribute(), that

accept the attribute's name as a String. For example, if the entity object has an
attribute called "DepartmentName," you can access this value by
calling getAttribute("DepartmentName") or setAttribute("DepartmentName",
"Marketing").
 If you generate an entity object class, it will contain typesafe getters and setters
for each attribute. For example, if the entity object has an attribute,
"DepartmentName," and you have generated an entity object class, you can
access this value by
calling getDepartmentName() or setDepartmentName("Marketing").
Entity Object Class (EO) (instance of it is a row ).
EntityImpl - Represents the Row (Data Instance)

 EntityImpl is the (data object) that: (represents a single row (or instance)) of
data in the business object layer.

o For example, if you have an Employee entity, an( EntityImpl object will
represent a single row in the Employee database table). (It holds the
attribute values for this particular instance of data, such as id, name,
salary, etc.)

 EntityImpl (is responsible for the data management of this specific row), such
as:

o (Setting and getting values for its attributes (e.g.,

employee.setSalary(50000)).)

o (Validating data based on business rules.)

o (Managing the row's lifecycle (new, modified, deleted).)

o :((Persisting the row (e.g., executing save() to commit the changes to the
database).)

 In short, EntityImpl is (the row of data and the object you interact with in your
application to manipulate that data. ) It represents (a single business object
instance (a row in the database table).)
 The framework will automatically create entity instances based on the
metadata(XML) and handle the database operations for you.

In Oracle ADF (Application Development Framework),( XML is used to define

the structure and metadata of Entity Objects (EO) ) (which helps in the
automatic generation and instantiation of the Entity Object Class (EO).) When
you don’t directly extend the Entity Object Class (oracle.jbo.server.EntityImpl),
Oracle ADF can still create instances of Entity Objects based on the XML
metadata or JPA annotations, (without needing you to write a custom Java
class for the entity itself.)

Let’s break down how this works and what happens when you don’t directly
extend the Entity Object class.

1. Entity Object Class (EO) and XML Configuration

In ADF, (Entity Objects represent rows from the data source (like a database
table).) (The metadata that describes the entity’s attributes), (relationships), and
(how it maps to the database) is (typically defined in XML) (or annotations in the
case of JPA).

The (XML configuration can describe how an Entity Object maps to a database
table and how it behaves, but if you don’t extend the Entity Object class, ADF
can still generate the necessary functionality automatically) from this
metadata.

How Does ADF Create Instances of Entity Object Class (EO) Without
Extending It?

1. Using Default ADF Classes:

 EntityImpl: By default, if you don't write a custom Entity Object class (i.e., don’t
extend oracle.jbo.server.EntityImpl),( ADF uses the oracle.jbo.server.EntityImpl
class as the base class for entity objects). (It manages basic operations like
fetching attributes, updating values, and supporting persistence operations.)

 Metadata Handling: ADF can still create Entity Object instances based on the
metadata defined in XML (typically .xml files or .jpx files in ADF). (This metadata
file specifies the attributes, primary keys, and relationships for the entity), and
ADF uses this( XML file to construct the entity object dynamically during runtime.)

2. How ADF Uses XML for Entity Object Creation:

 XML Definition: In the XML file (such as EmpEO.xml or a Business

Components XML),( the attributes of the entity (like columns in a database
 table) are mapped,) (and these are used by ADF to create instances of the
Entity Object during runtime.)

(The XML file provides the metadata for ADF to instantiate the entity class and assign
values to its attributes.)

 Automatic Instantiation: Even if you don’t write a custom EntityImpl class, ADF
can instantiate the Entity Object using the default EntityImpl class and
populate it with data fetched from the database using the metadata defined in
the XML file.

Example:

Consider the following XML metadata that defines an Employee entity (mapped
to a database table):

(Without a Custom Entity Object Class: ADF uses the default EntityImpl
class and this XML metadata to create instances of the EmployeeEO entity,
manage its attributes, and handle its persistence operations automatically.)
You don’t need to write any Java code for the Entity Object itself.

 (With Custom Entity Object Class: If you need to add business logic (like
validations, transformations, or calculated fields), you would create a custom
EmployeeEO class that extends EntityImpl. This custom class allows you to
implement methods for these operations.)
Entity Definition Class (ED)

why we need EntityDefImpl while we have xml file contains this information ?

1-XML Metadata Defines the Structure (Static Information)

XML files in Oracle ADF contain static metadata that defines the structure of your entities. This
includes things like:

 The attributes of the entity (e.g., id, name, salary).

 The mapping of entity attributes to database columns.

 Primary key information.

 Associations and relationships to other entities.

 Validation rules.

This metadata typically gets generated or provided by tools like JDeveloper when you create
your entities, and it is often stored in XML files (e.g., Employee.xml, Department.xml, etc.).

2. EntityDefImpl Bridges Static Metadata and Runtime Behavior

While the XML file contains the static definitions, EntityDefImpl is the runtime class that
processes this metadata and manages the interaction between the metadata (from the XML)
and entity objects (like EmployeeImpl, DepartmentImpl).

In simpler terms, EntityDefImpl acts as a runtime manager that reads the metadata from the
XML files and applies it to the live objects (the entity instances) during execution. The entity
objects (e.g., EntityImpl) interact with EntityDefImpl to perform operations such as inserting,
updating, deleting, and querying entities, and EntityDefImpl helps in managing the entity’s
metadata behavior at runtime.

3. Why Is EntityDefImpl Needed at Runtime?

Here are the key reasons why EntityDefImpl is required, even though XML files contain
metadata:

a. Loading and Interpreting XML Metadata at Runtime

 The XML files are static — they contain definitions of the entity and its structure.
However, they don’t actually know how to manage entities at runtime.

 EntityDefImpl loads and interprets this static metadata during the application runtime
and provides the necessary logic for working with Entity Objects (Eo) in the context of
database transactions, business logic, and UI interactions.

For example:

 If an entity has an attribute id that is an auto-generated primary key, EntityDefImpl will

provide the logic for auto-generating that key when a new entity instance is created.

 It also determines how to map data from the XML definition to the database at runtime
(when performing CRUD operations).

Dynamic Access to Metadata

 EntityDefImpl provides dynamic access to the metadata. For example:

o You can use EntityDefImpl to programmatically retrieve the names of all

attributes for an entity.

o You can find out the type of each attribute or validate it dynamically based on the
metadata.

Dynamic Access to Metadata

 EntityDefImpl provides dynamic access to the metadata. For example:

o You can use EntityDefImpl to programmatically retrieve the names of all

attributes for an entity.

o You can find out the type of each attribute or validate it dynamically based on the
metadata.

Performing CRUD Operations

 When you perform CRUD operations (Create, Read, Update, Delete), EntityDefImpl is
responsible for providing the necessary functionality to translate those operations into
 database queries (SQL). It knows how to map the entity’s attributes to database
columns.

o For example, when you call save() on an entity (EmployeeImpl), EntityDefImpl

uses the metadata from the XML to generate the correct SQL to persist or
update the entity in the database.

o Similarly, when deleting an entity, EntityDefImpl ensures that the appropriate

DELETE SQL is generated based on the entity's primary key (which it reads from
the metadata).

Without EntityDefImpl, ADF would not have a way to dynamically understand how to convert
an entity's data (its attributes) into SQL statements or how to manage complex mappings like
relationships and associations.

Customizing Metadata and Runtime Behavior

 If you need to customize the behavior of the metadata at runtime (e.g., dynamic
validation, custom mapping, etc.), EntityDefImpl allows you to do that.

o For example, you might want to modify or add custom logic when an entity is
saved or loaded. This can be done by extending EntityDefImpl and overriding its
methods.

The XML file cannot provide this level of flexibility because it’s just a static file that defines the
structure — it doesn’t allow you to add business logic or customize runtime behavior.

Entity Relationships

 EntityDefImpl manages relationships between entities, like associations and

references.

o For example, in a Department and Employee relationship, EntityDefImpl helps

manage one-to-many or many-to-one relationships between entities, ensuring
that foreign key constraints are respected when performing operations like
saving, updating, or deleting related entities.

The XML file defines the relationship structure, but EntityDefImpl provides the runtime
behavior for maintaining these relationships, especially when entities are persisted in the
database.

Transactions and Data Caching

  EntityDefImpl integrates with ADF’s transaction management and data caching
mechanisms. For example:

o When you save an entity, EntityDefImpl helps manage how the changes should
be committed or rolled back as part of a transaction.

o EntityDefImpl works with ADF's cache to track and maintain the state of entities
across different requests or transactions, ensuring that the same entity isn’t
loaded multiple times unnecessarily.

Summary: Why EntityDefImpl Is Needed

In summary:

 The XML files define the structure of the entity (its attributes, associations, etc.), but
they are static and don’t have any behavior or logic attached to them.

 EntityDefImpl is the runtime class that provides the functionality for interpreting and
managing that static metadata. It:

o Loads the metadata at runtime.

o Performs CRUD operations.

o Dynamically maps entity data to database tables.

o Manages relationships, validations, and other business logic.

o Allows for customization of how the entity behaves during runtime.

Thus, while the XML files are necessary for defining the structure, EntityDefImpl is crucial for
providing the runtime functionality needed to make your entity data interact with the
database, handle operations, and support application logic dynamically.