The frontend part is constructed from several layers. In a web-based application, these are normally arranged in the common model-view-controller (MVC) pattern, as illustrated in the following figure:

The view layer is interacting with the user, thus displaying data as well as receiving updates and user actions. The controller layer is in charge of interpreting user actions and deciding which screens are presented to the user in which order. The model layer is representing the backend business services to the view and controller layers, thus hiding the complexity of storing and retrieving data.

This architecture implements a clean separation of duties—the page doesn't have to worry about where to go next because that is the task of the controller. The controller doesn't have to worry about how to store data in the data service because that is the task of the model.

The backend part consists of a business service layer that implements the business logic and provides some way of accessing the underlying data services. Business services can be implemented as API code written in Java, PL/SQL, or other languages, using web services or a business service framework such as ADF Business Components.

Under the business services layer, there will be a data service layer actually storing persistent data. Typically, this is based on relational tables, but it could also be XML files in a filesystem or data in other systems accessed through an interface.

Entity objects (EOs) take care of object-relational mapping, making your relational tables available to the application as Java objects. Entity objects form the base that view objects are normally built on, and all data modifications go through the entity object. You will normally have one entity object for every database table or database view that your application uses, and this object is responsible for producing the correct SQL statements to insert, update, or delete data in the underlying relational tables.

The entity objects help you build scalable and well-performing applications by intelligently caching database records on the application server in order to minimize the load that the application places on the database.

Like entity objects are the middle-tier representation of database tables and database views, associations are the representation of foreign key relationships between tables. An association implements a connection between two entity objects and allows ADF to connect data in one entity object with data in another. JDeveloper is normally able to create associations automatically by simply inspecting the database, but in case your database does not contain foreign keys, you can build associations manually to let ADF know about the relationships in your data.

While you don't really need to make any major decisions when building the entity objects for the Proof of Concept, you do need to consider the consumers of your business services when you start building view objects—for example, what information you would display on a screen.

View objects are typically based on entity objects, and you'll mainly be using them for two purposes:

The data handling view objects are normally specific to each screen or business service. One screen can use multiple view objects. If you have master-detail data, for example, departments containing employees, you create one view object for each master-detail level you wish to display on your screen (for example, one department and one employee view object).

One view object can pull together data from several entity objects. If you need to look up a reference value from another table, you don't need to create a separate view object for this. For example, an employee entity object might contain only the department number. If you want your view object to display the department name, you need to include the department entity object in the view object in order to retrieve it.

The LOV view objects are used for drop-down lists and other selections in your user interface. They are typically defined as read-only, and because they can be reused, you can define them once and re-use them everywhere you need a drop-down list on a specific data set.

View links are used to define the master-detail relationships between the view objects and are typically based on associations (again, they are often based on foreign keys in the database).

The following figure shows an example of two ways to display data from the familiar EMP and DEPT tables found in the SCOTT schema:

The left-hand side illustration shows a situation in which you wish to display a department with all of its employees in a master-detail screen. In this case, you create two view objects connected by a view link. The right-hand side illustration shows a situation in which you wish to display all employees together with the name of the department they work in. In this case, you only need one view object pulling together data from both the EMP and DEPT tables through the entity objects.

Application modules encapsulate the view object instances and business service methods necessary to perform a unit of work. Each application module has its own transactional context and holds its own database connection. This means that all of the work a user performs using view objects from one application module is part of one database transaction.

Application modules can have different granularity, but typically, you will have one application module for each major subsystem in your application. However, there is no limit to the amount of functionality you can put into one application module—indeed, it is possible to build a small application using just one application module.

If you wish, you can combine multiple application modules inside one root application module. This is called nesting and allows several application modules to participate in the transaction of the root application module. This also saves database connections because only the root application module needs a connection.

The preferred way of building the user interface in an ADF enterprise application is with JavaServer Faces (JSF). JSF is a component-based framework for building web-based user interfaces that overcome many of the limitations of earlier technologies such as JavaServer Pages (JSP).

In a JSF application, the user interface does not contain any code but is built from the configurable components of a component library instead. For your application, you'll want to use the sophisticated ADF 12c JSF component library known as the ADF Faces Rich Client.

One of the great improvements that ADF 11g and 12c offer over the earlier ways of building web applications is the concept of ADF Task Flows.

It had long been clear to web developers that in a web application, you cannot just let each page decide where to go next—you need the controller from the MVC architecture. Various frameworks and technologies have implemented controllers (both the popular Struts framework and JSF have this), but the controller in ADF Task Flows was the first one capable of handling large enterprise applications.

An ADF web application has one unbounded task flow where you place all of the publicly accessible pages and define the navigation between them. This corresponds to other controller architectures such as Apache Struts. The user can enter an unbounded task flow on any page. However, ADF also has bounded task flows, which are complete, reusable mini applications that can be called from an unbounded task flow or from another bounded task flow.

A bounded task flow has a well-defined entry point, accepts input parameters, and can return an outcome back to the caller. For example, you might build a customer management task flow to handle customer data. In this way, your application can be built in a modular fashion—the developers in charge of implementing each use case can define their own bounded task flow with a well-defined interface for others to call. The team building the customer management task flow is thus free to add new pages or change the navigation flow without affecting the rest of the application.

The concepts behind ADF Task Flows have influenced the JSF 2.2 standard, where this approach is known as Faces Flows. However, ADF Task Flows have more features and a different technical implementation.

In bounded task flows, you can define either pages or page fragments. Pages are complete web pages that can be run on their own, while page fragments are reusable components that you can place inside regions on pages.

You can choose to build your ADF application as either a traditional web application or a Rich Internet Application (RIA). A traditional web application consists of pages—when the user interacts with the application, the whole browser window will redraw, thus showing the next page of the application. In a Rich Internet Application, on the other hand, you will have a small number of pages (possibly only one) and a larger number of page fragments. These page fragments will dynamically replace each other inside a region on an application page, so the user sees only a part of the page change. If you choose this technique, your application will seem more like a desktop application than a traditional web application.

On your pages or page fragments, you can add content using layout components, data components, and control components: