Introduction to ADF-BC

As far as ADF is concerned the main data source which is also called as the data model in generic terms is based on ADF-BC (Business components)

ADF-BC is the data model layer for ADF.ADF-BC has the following prime components.


1.The Entity objects or EO's
2.The View objects or VO's and
3.Association's and Viewlink's.

4.The Application modules or AM's
5.The Business Component Tester

The EO/VO is similar to Object relational mapping elements like TopLink.Thanks to Steve Muench for clarifying on where TopLink stands

So in essence EO/VO provide a standad way of interacting with database tables and serve as the data model source.Getting into more details we have

The Entity Object

An EO represents a table in simple terms.It defines the tables attributes the data types,validation on the data,the primary keys and what not the entire business logic that needs to be defined for pushing data into the target table.

So the EO serves as the sink for data by validating it and finally storing it in to the tables.
Then we have,

The View Object

The view object in simple terms is the data source.It provides data for interacting with it.A VO can be based on EO's which in case are similar to SQL queries used to extract data,or it can be programatically populated or it can be populated with a static list.

How ever VO's based on EO's are mostly used.The view object is used to query data and serve as the data source,The EO serves as the sink.While a few validation can be done even on the VO level its better to have business logic on the EO's for reasons entitled below:

EO cache is the same for all VO's
?When a two VO's are based on an EO both of them share the same entity cache.At run time when a VO executes a query the resultant data is split into its respective entity object records and stored in the entity cache.This helps multiple VO's to refer same set of data there by reducing memory map and also multiple validation rules for all EO's.This is similar to normalization.

For example let's say we have two EO's, a department EO and employee EO and their respective VO's are department VO which queries department information and employee VO which joins department and employee information together based on department ID.

At run time when the data is queries for an employee record lets say we queried [empname,empid,deptid,deptname] (assuming employeename and empid and deptname and deptid's are the only columns in respective tables).

Now ADF splits the employee vo record into its constituent records as [empname,empid] and [deptname,deptid] and pushes each record in to respective entity cache.This reduces memory foot print because department VO need not bring more data into memory.More over id deptname is updated then one instantly sees the same value in employee info instantly.

Thus having validation at EO level will help in providing a central point for all VO's dependent on them.It's not just data that is shared across VO's there are many more which one comes to know in future blogs.


Association and Viewlink

They define the join or the link among EO's and VO's.Association defines link between EO's.They can be considered as PrimaryKey/ForeignKey relationship between tables.
The Viewlink is for a VO.It defines the Join conditions.A viewlink can be based on an association or based on attributes,Basing viewlinks on associations have the same advantage of entity cache and few more which are unveiled later.

The Application Module

The application module packages the VO's and serves as the data control.It creates and manages the database transaction.For ADF Model layer its only Application Module which exposes the data needed by the client.So for an end user the interaction and transactional capabilities are provided by the application module.How ever there are many advanced features which i will explain as we progress.

The Business Component Tester

The mostly used component of the model layer is the tester, which is used to run and check the data model that is implemented.This serves as the first line of defense to see if data is exposed as we need it and to test the data model with out a need to create a UI.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21900589/viewspace-691658/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21900589/viewspace-691658/