The 5 Minute Guide to Oracle ADF

by Kenneth Lange  

The short, but not so sexy intro is that Oracle ADF is a Java-based web framework, which is often used for large-scale enterprise application.

Oracle is dead serious about it. They are using it to develop their own enterprise applications (a multibillion dollar business) and 3,000 of their internal developers are using it for application development.

The promise of ADF is productivity: If you let the framework handle most of the low-level technical stuff (like database interactions) then you can use your time to develop business features that your customers actually care about.

That’s all very nice, you might think, but does it actually work?

ADF at 50,000 feet

If you look at Oracle ADF from a very high level, it’s made up of a front end (i.e. user interface) and a back end (i.e. business services).

The user interface is unsurprisingly where the application interacts with the user, and the business service layer is where the application interacts with the database.

Each of these two layers is made up of multiple modules. We’ll dive into each module in the following sections, but here’s a sneak preview for those of you who cannot wait!

Oracle is really hyped about ADF being an open and modular framework, which means you can replace most of the modules in the diagram above if you want to. You can even use Microsoft Excel as the front end (I’m not kidding you!)

User Interface

The user interface in ADF is loosely based on the MVC pattern, so if you are already familiar with other web frameworks based on this pattern, you can probably learn ADF pretty fast.

The user interface is made up of three modules:

  1. ADF Faces: This is where you create the pages that the users interact with. It is XML-based and if you are familiar with tag libraries (from JSP or JSF) you’ll quickly feel at home.
  2. ADF Task Flows: This handles the navigation between pages in your application. The idea is that you structure your pages in a flow to perform a given task. For example, to create a new employee.
  3. ADF Bindings: This is where you bind the UI widgets to the underlying business services (i.e. database), so the widgets know where to get their data from.

The nicest thing about the ADF UI is that it comes with a huge set of standard UI widgets. For example, pie charts, an “Export to Excel” feature, and other crowd-pleasers for the corporate world.

You can get an idea about the widgets available in the component palette below:

To use one of these widgets, you simply drag it into your page, bind it to a business service, and there you have it! Nice and easy :-)

Business Services

While the ADF Framework offers multiple ways to implement business services (i.e. the back end), the most common one is to use ADF Business Components on top of an Oracle Database (which in ADF lingo is called a “data service”).

This makes good sense since most enterprise applications are about manipulating massive amounts of data stored in a database.

ADF Business Components is made up of these elements:

Let’s just for fun take a bottom-up tour of them:

  • Entity Object: There’s basically a one-to-one mapping between a database table and an entity object. So if you have an employee table in the database, you’ll also have an employee entity object. The entity object handles the object-relational mapping and enforces business rules (i.e. employee start date must be before end date, etc.)
    • Association: Represents a foreign key in the database. For example, there could be a foreign key between an employee and department table to tell us which department that the employee works in.
  • View Object: A view object is similar to a database view. You basically make a query that gets some columns, from one or more entity objects, using some search criteria. For example, you may want to have a department overview view object that combines data from some employee and department entity objects.
    • View Link: Similar to associations, just between view objects. You might wonder why bother with all these links? The idea is that the user interface can automatically figure out master-detail relationships when you specific these links.
  • Application Modules: These provide the user interface with a nice interface to your entity and view objects. The application module handles the database connection and transaction scope, and creates the necessary instances of the view objects and entity objects. It’s similar to Martin Fowler’s Unit of Work pattern.

That’s it! We have now reached the end of our speedy tour of all the major elements in the ADF Framework.


So does ADF fulfill its promise of productivity? I would say it depends (I know, pretty annoying answer!) The consensus seems to be that ADF is a complex framework with a steep learning curve, but once you have learn it, it can be a pretty powerful framework for enterprise applications.

The strongest argument against its productivity claims is probably that some of the newer javascript frameworks (like Angular) can be faster to develop in compared to ADF (and similar frameworks).

The strength of Oracle ADF in this fight (at least, in the enterprise arena) is that it’s so strongly backed by Oracle that you can feel pretty confident that it has staying power, which is absolutely vital for enterprise applications, and which is not always something that younger frameworks can offer.

So is Oracle ADF worth learning? I would say so, at least, if you (like me) are fascinated with large-scale enterprise application.

Share this post:


Subscribe to this blog:

Just enter your email below and press the button:


Related Posts: