Application architecture

Once you have found out what you need to build and how much you want to build, you now have to choose your application architecture. The architecture determines how many workspaces you have and which components go into which workspace.

The ADF framework is very flexible and allows you to build applications in many different ways, so there is a large number of possible architectures. Three good ones are:

In a simple architecture, you build the entire application in one workspace. You saw an example of this approach in the Proof of Concept application in Chapter 1, The ADF Proof of Concept. Business components go into a model project in the workspace, and task flows and pages go into a view/controller project. This approach works well for small applications that will be built by one or two developers.

If your application is larger than 5-10 bounded task flows and/or more than two people need to work on it, a modular architecture is a good approach. In this approach, you place common elements (templates, visual identity, entity objects, and view objects for value lists) in a common application workspace and then use the output of that workspace in a number of subsystem workspaces. As described earlier, your subsystems then each contain a specific subset of the total application functionality (view objects, task flows, and page fragments), and all of the subsystems are collected into one master application workspace. This architecture is illustrated in the following figure:

If your organization is going to be building many ADF applications, it makes sense to extend the modular architecture to the enterprise architecture. In this approach, you keep the enterprise common objects (base-level templates, visual identity, possibly entity objects, and view objects for global entities) in an Enterprise Common Workspace and then use the output from this workspace in a number of Application Common Workspaces. These Application Common Workspaces add features that are specific to each application (entity objects and value lists specific to the application). Like in the modular architecture, each application is then built with a number of subsystems that are collected into one or more master application workspaces. This architecture is illustrated in the following figure:

Note that the enterprise architecture allows you to build several master applications and even use the same subsystem in two different applications.