Introduction to Oracle ADF

Now, lets start with some basic introduction about ADF. Before that, for those who are familiar with Struts framework, we'll do a little comparison of ADF with struts.

Struts vs Oracle ADF

Similarities:
First thing is that both Struts and ADF are frameworks. Both of them use MVC (Model-View-Controller) architecture. Detailed ADF architecture is documented here. And as struts has it's own config file struts-config.xml, ADF has the config file called adfc-config.xml. As Struts has it's own framework API classes, ADF has it's own framework classes and API.

Differences:
Struts doesn't have any support for declarative development whereas ADF has support for declarative development. Struts doesn't have it's own components to use in development whereas ADF comes with it's own Oracle ADF faces components. Struts doesn't have any default persistence mechanism (i.e., default ORM) where as ADF has default persistence mechanism if we use ADF business components.

How to understand or get an idea about ADF as a new-bee?
Easy. Assume yourself understanding some database concepts. As you might be already familiar with DB concepts, it'd be a better idea to understand ADF concepts from DB perspective.

Before going into the details, ADF has some terminology you would need to know. I'm comparing the Database objects with ADF objects.

1. Database Table vs. Entity Object (EO): Both are analogous to each other. i.e., the entity object is built on top of Database table and it contains the table columns as attributes. And the entity object will inherit the database constraints as the attribute level validations. Examples of attribute level validations are given below:

Eg., if the column 'EmpName' in Emp table is 'Not Null', then the attribute 'EmpName' is marked as 'mandatory' by default and it'll fire mandatory field validation if you're trying to create Emp record without providing 'EmpName'. Similarly if you give the EmpName column as 50 characters, Entity object will have a precision validation for the attribute and will allow to enter only 50 characters. The same will apply for numeric data type columns as well.

That said, you don't need to rewrite your validations for default database constraints. You'll get them into entity objects by default.

2. Database View vs. View Object (VO): Again both of them are analogous to each other. You'll define a database view on top of multiple tables (which is basically a query join of multiple tables). Similarly ADF View Object is actually based on multiple Entity Objects. And, when you join multiple tables, generally you'll join them based on some foreign key. The same applies to View Objects as well.

3. Foreign Keys relationships vs. Entity Associations: Both of these things are analogous to each other. We'll define associations between entity objects based on the foreign key attriutes. Based on these associations, the join condition in View Object where clause will be generated automatically when the view is based on the Entity Objects having associations.

4. SQL Queries vs. Application Module (AM) operations: Any application would generally have four requirements. They are Search, Create, Update and Delete. I'm giving the simple example that uses SQL queries to perform these operations.

Let us take simple example of Employee-Department (Emp-Dept) tables of SCOTT schema. Now with just basic DB knowledge, how will you accomplish the above mentioned four operations for Emp table? I'll assume you'll give the following answers.

1. Search: You'll write a simple SQL query to query the database with where clause that corresponds your search criteria. For e.g., you'll write the below query to retrieve the employees list whose name starts with letter 'M':

select * from emp where ename like 'M%';

2. Create: To create a new Emp record, you'll write an SQL 'insert' query with the values for the new Emp record.

3. Update: To update an existing Emp record, you'll again write an SQL 'update' query with the 'where' condition matching which record has to be updated.

4. Delete: Similarly to delete an existing Emp record, you'll write an SQL 'delete' query with the 'where' condition matching which record to be deleted.

Finally coming to ADF, we'll add the ADF View Objects to something called Application Module (AM) which is a runnable instance. We'll be able to perform all of the above mentioned operations (like Search, Create, Update and Delete) via Application Module can do operations declaratively.

We'll see all of the above mentioned ADF objects and their implementation in detail in coming posts. So, stay tuned :)