ADF Business Components - Part2

Entity Object & Entity Classes in Detail

Entity objects Business Rules:

It can do more than just be representations of data. They can also encapsulate the business rules pertaining to the data they represent. 

An entity object can:

    Enforce validation rules for attribute values

    Calculate default values for attributes

    Automatically calculate the values of transient attributes

   Automatically react to data changes 

 Overview of Entity Classes:

Entity object definitions are handled by three classes in the ADF BC library. They are referred to as the base entity classes:

oracle.jbo.server.EntityImpl  Each instance represents one row in a database table. This class has all the methods needed to read, update, insert, delete, and lock rows. 

oracle.jbo.server.EntityDefImpl  Instances of this class act as wrappers for the entity object definition XML files.   The class contains methods allowing you to dynamically change the definition of the entity object itself – to add or remove entity attributes or to change the properties of these attributes.

oracle.jbo.server.EntityCache  An instance acts as an entity cache – a memory location holding instances of a particular entity object definition in use in a single transaction. Methods are provided that manipulate rows in the cache. You normally do not use these methods directly. They are for internal use.

If you need further customization, you can generate custom entity classes that extends one or more of them. For example, for a particular entity object definition, Departments, you could generate any or all of the following:

DepartmentsImpl     An entity object class, which extends EntityImpl

DepartmentsDefImpl     An entity definition class, which extends EntityDefImpl

DepartmentsCollImpl     An entity collection class, which extends EntityCache

These classes may be customized for a particular application.

An entity object class:

           An entity object class is a subclass of EntityImpl that a particular object     definition can use to represent its instances. They have the same name as the entity object definition with an "Impl" suffix. The entity object definition "Departments“, for example, would have an implementation class called "DepartmentsImpl".  

Entity Attribute Accessors:

Entity object classes provide accessors (getters and setters) for each attribute. For example, DepartmentsImpl will by default contain the getDepartmentId() and setDepartmentId() methods.  

EntityImpl contains the getAttribute() and setAttribute() methods which also allow you to retrieve and change attribute values, but accessors in the entity object class have two advantages.

Entity Attribute Accessors Are Typesafe:

Entity attribute accessors are typesafe, they take fully typed objects as parameters and have fully typed return values.

For example, DepartmentsImpl will by default contain the method getDepartmentId(), which returns a Number, and the method setDepartmentId(), which returns void and takes a Number argument.

The following code causes compile-time errors 

 

EntityImpl's attributes can still be accessed directly using the following methods (although they are not typesafe):

EntityImpl.getAttribute() Takes a String (attribute name) argument and returns a java.lang.Object

EntityImpl.setAttribute() Takes a String (attribute name) and an Object as arguments

If you forget the Java type of your attributes you will not get a compile-time error, but the application will throw an exception at runtime (making things harder to debug).

Neither of these lines will cause a compile-time error, but they will throw exceptions at run-time:  

Using entity attribute accessors can make it easier to debug typos in attribute names.

For example, the first line below will cause a compile-time error, and the second line below will throw an exception at run-time. 

 

Overriding Methods in EntityImpl:

You can also override various methods in the EntityImpl class to implement other business logic. By overriding the EntityImpl.create() method, for example, you can implement defaulting logic or trigger events whenever a row is created. 

Entity Definition Classes:

Entity definition classes extend oracle.jbo.server.EntityDefImpl. 

Unlike entity object classes, which are usually generated for most entity objects, there are only two reasons for creating an entity definition class are:

To override the method EntityDefImpl.createDef(), which is called as soon as the entity object is loaded into memory. This allows you to dynamically change the definition of the entity object without writing code in every application that uses it.

The need to provide a place to put a custom method that affects an entire table, as opposed to a single row (which should be in an entity object class) or all rows returned by a particular query (which should be in a view object class).

Entity Collection Classes:

Suppose an application has just inserted a row into, or accessed a row from, the DEPARTMENTS table. When it did, an instance of the DepartmentImpl object was created. Usually the application will need to access the row again in the near future, so rather than destroying the object, ADF BC stores it in a cache called the entity cache.

When a row is changed, instead of making a time-consuming round trip to the database, ADF BC simply makes the change to the DepartmentImpl object in the entity cache until the transaction is committed or the change is manually posted.

  Usually an entity cache is implemented by an object of the type oracle.jbo.server.EntityCache. You can also generate an entity collection class (extended from EntityCache) if you need to change the behavior of the entity cache. Entity collection classes have the same name as the entity object with a "CollImpl" suffix. For example, the "Departments" entity object would have the definition class called "DepartmentsCollImpl".