Where Does Oracle ADF Fit Into the Development Landscape?
by Sten Vesterli
How Much Freedom Do You Need?
One important dimension to consider when choosing a development tool is how much freedom you want to build the user interface. Ask yourself whether your application is data driven or user-interface driven.
Some applications are data driven, which means the user interface looks like the underlying data structure. If the data model contains a table of customers, the user interface will contain a screen showing all the fields for a customer. If there is a table of orders for a customer that is connected through a foreign key, the user interface will contain a master-detail screen showing a customer and his or her orders.
Other applications are user interface driven. This means that the user interface is freely developed by UI designers working with end users to create screens that closely match how users of the application do their work. How that work is done is unconstrained by the underlying data model.
It is easier to build a data driven application. The data designer just needs to identify the entities involved in the subject area (for example: customers and orders) and their relations to each other. When the entities are modeled as database tables, the user interface largely designs itself.
Building a user interface driven application takes more work. The data designer must still build a good data model, but there is also work that must be performed by the user interface designers, and then the developers must tie together the desired user interface with the data model. In return for this investment, the organization gets an application with higher end user productivity, higher user satisfaction, and fewer errors.
The different tools available in the Oracle landscape have different architectures and implement different layers of the total application. A modern application typically has three tiers:
- Data storage
- Business logic
- User interface
As an Oracle developer, the data storage tier will most likely be an Oracle database, and the power of PL/SQL allows you to place a part of your business logic in the database as well. But on top of the Oracle database, the different tools have different approaches as illustrated in the following figure:
Both Forms and APEX are mainly monolithic: They contain both business logic and user interface. This makes them well suited to building data driven applications, but not so much for building user interface driven applications.
Oracle ADF, on the other hand, separates business logic from user interface. The business logic is implemented in ADF Business Components (ADF BC) and the user interface is implemented with ADF Faces. This imposes a cost in development time and complexity but provides the power and flexibility to build a user interface driven application.
ADF Business Components and ADF Faces have their own highly effective and easy-to-use connection, but they can also both use REST web services. ADF Business Components can be published as REST web services for other tools to consume, and ADF Faces can consume REST web services provided by other tools.
VBCS is mainly a tool for building the user interface layer based on existing REST web services, even though it does have some basic capabilities to provide simple REST services. Oracle JET is exclusively a user interface tool and depends on REST services provided by some other tool. Oracle REST Data Services (ORDS) can easily provide simple REST services based on database tables, but it takes a lot of PL/SQL programming to provide true business logic REST services.
How Big an Application?
Another consideration is how large the application is going to be. ADF has powerful modularization features built in, easily allowing development teams of hundreds of people to work on one application at the same time without getting in each other’s way. ADF also supports very fine-grained version control where you can track the history of each artifact.
In monolithic tools like Forms and APEX, the units of version control are larger – in a Forms application, the unit of version control is the individual Form, while an APEX application can only be versioned whole. This limitation in APEX of only being able to version control entire applications can be partially overcome by splitting a large APEX application into many smaller applications, but such an approach requires strong developer discipline.
About the Author
Sten Vesterli is the author of the Oracle ADF Survival Guide. He has worked with almost every development tool Oracle has produced in the last several decades, including ADF, APEX, JET, Application Developer Cloud Service, JDeveloper, SQL Developer, Oracle Portal, Oracle WebDB, Oracle BPEL, Collaboration Suite, Designer, Forms, Reports, and even Oracle Power Objects. Oracle has recognized Sten’s skills as an expert communicator on Oracle technology by awarding him the prestigious title, Oracle ACE Director.
This article was contributed by Sten Vesterli, author of the Oracle ADF Survival Guide.