Please note: this document is under rapid development.
Note: this page is a very high level overview of the layer and class structure. For more detail, especially concerning the interface between classes, see Platypus tools.
An Enhydra application divides into three layers: presentation, business and data. The Platypus framework dictates a number of Java clesses to be generated in each layer. The layers and classes are shown here.
Consider the AddPersonResults presentation object, which displays information from the Person table in the database. Several classes will be involved in serving this page.
When the Enhydra server receives a request for the AddPeriodResults URL, it will translate this into an invocation of the AddPersonResults class.
The presentation layer's AddPersonResults class will invoke a AddPersonResultsBO class in the business layer.
The AddPersonResultsBO will communicate with the PersonBO class for information from the database. The PersonBO class is the business layer's access point to the data layer.
The data layer consists of various classes as created by DODS.
Every PO in the presentation layer has a corresponding class in the business layer.
Every table in the database has a number of classes in the data layer including a DO and BDO. For each table, there is a business layer class which extends the data layer BDO class.
To obtain the information needed by the presentation layer, the AddPersonResultsBO class will invoke the PersonBO class in the business layer, which will in turn invoke the PersonDO class (and possibly others) in the data layer.
Thus, we see that the presentation layer is structured around the pages served to the user and the data layer is structured around the tables in the database. The main function of the business layer is to switch page based requests into database table based requests. Hence, the business layer contains both page and table based classes.
Under Platypus, the presentation layer has a limited role. It is reponsible for manipulating the DOM structure. However, it does no manipulation of the data being inserted into the DOM. The presentation layer deals almost entirely with data in string form. It requests data from the business layer via method calls which take string parameters, and receives data back in string form.
Some exceptions to this string rule exist. For example, the business layer returns the number of records found by a query in integer form, and the presenation layer requests a particular record from a query using an integer parameter. However, there are very few exceptions. For example, if a page includes a series of prices, and a total of the prices, these are all converted to string form in the busness layer.
Platypus' current integration to the data layer is via code generated by DODS. Any other form of data access (LDAP, etc) would require hand crafted code.
In the Platypus world view, the business layer handles much of the work in the application. As mentioned above, the presentation layer works with strings while the business layer handles the rules for number manipulation (totals, etc) and other processing. Any exceptions generated in this layer or the data layer are trapped or rethrown as one exception type only (ApplicationException). This reduces the complexity required in the presentation layer.
Naturally, the business layer isolates the presentation layer from the data layer. Platypus enhances this concept by having different business objects for interfacing to the presentation and data layers. These business objects communicate with each other to provide the link from presentation to data.
Each PO has a class which is invoked when the server receives a request for the corresonding URL. Under Platypus, the relevant Java is divided between two classes. For example, the AddPersonResults class extends the AddPersonResultsBASE class.
The AddPersonResultsBASE class declares and initialises variables, and does much pre- and post-processing. The Platypus framework has enough information to completely generate this code - it does not need to be edited by the developer.
On the other, the AddPersonResults class does the detailed manipulation of the DOM structure. Platypus generates a skeleton for this class, but expects that the developer will be hand-editing the code.
This division into two classes simplifies the development process, removing from the developer's vision code which they do not need to see. It also simplifies modifying the Java if changes are made to the app's specification late in development.
For each PO invoked, a corresponding BO exists for the presentation layer's access to the business and data layers. In the case of the AddPersonResults mentioned above, the BO class is AddPersonResultsBO.
Assuming this class is in a maintenance section of the application and this section has its own maintenance subdirectory, the AddPersonResultsBO class extends a special directory wide class called MaintenanceBO.
The MaintenanceBO class is extended by all BOs in the maintenance subdirectory. The class allows common business logic code to be accessed by all maintenance BO classes.
Assuming the maintenance subdirectory is directly below the application base directory, then the MaintenanceBO extends the application base BO, e.g. if the application name is Timesheet, then the MaintenanceBO extends the TimesheetBO class in the base src/business directory of the application.
All BO files that are invoked by the presentation layer eventually extend the application base BO class. Application wide business logic can be embedded in this base class and accessed by the BO classes.