Wednesday, February 01, 2006

The Model: AM, Entities, Views etc.

As already mentioned in my first blog entry, ADF is composed by a multitude of layers within a large technology stack and these can be abstracted into the MVC pattern. In reality, the View and Controller layer in ADF is collapsed into the same layer and this is why most ADF applications actually consist of 2 independent projects within one ADF application, namely the Model and the ViewController. The following provides a quick and rudimentary explanation to what you will find in the Model part of such an application.

Application Module (AM)
This is your applications point-of-entry and essentially responsible for launching and managing the data-model beneith your applcation. Whichever Views and ViewLinks you may have created will not have any effect (be visible) before they are added to the AM. The default implementation of the AM is in which will have a main method for launching a default Swing test application which can come in very handy when debugging and testing your model layer. You may extend the default implementation, as is often nessesary, in order to satisfy various pre-condtions such as user authorization etc. For example, to lock a specific view (E.g. UserView) to only show records with the users own initials (CLB in my case), the following could be done:

protected void prepareSession(Session session)
this.getUserView().setWhereClause("UserView.initials = :initials");
this.getUserView().setWhereClauseParam(0, "CLB");

Whichever view is linked to the UserView, will "inherit" this limitation and thus provides an excellent way of ensuring users see only their related rows. This could not have been achieved by a pure static view since the view is dynamic by nature, adapting to whichever is signed in to the system.

Entity Objects
Entity objects are at the very heart of an ADF application and its responsibility is to encapsulate a database table (and its rows). The framework will require there be a primary key column before doing so, the reason for this will be obvious in a moment. A java representation instance is required in order to model layers on top and add business logic. ADF can overide the default Java representation for an Entity and expose type-safe accessor methods for
association attributes rather than the default getAttribute("
"). In JDeveloper an entity has both an instance (.java file) and related metadata (.xml file).

Handles relation and cardinality between two entity objects. These attributes allow you to navigate from one entity instance to either another entity instance or a collection of related instances, depending on the cardinality of the association in question. This can be done by using
") where the framework will use the association to perform a findByPrimaryKey() on the related table and fetch the data for you. Associations are paramount to making views over multiple Entities, by using the association information to automatically construct the underlying join (WHERE clause). Associations are just metadata for the entities, stored in corresponding XML files.

View Objects
In the simplest sence, a view is nothing more than a SQL query. However, even if a view is composited over multiple Entity objects, it can be updated just as if it was an atomic table in the database. This is done providing the "reference" attributte for the Entity object is checked and is what distinquishes an ADF view from a database view.

Handles relation and cardinality between two view objects. ViewLink's connect two views in a Master-Detail fashion, where the master view provides an overview og more detailed data, usually as a 1:* relation between views. When a ViewLink is created between two views, the newly linked attributtes become available to each view.


Post a Comment

<< Home