 |
 |
 |
A Thought Experiment: Rationale |  |
 |
 |
ui GUI toolkit
"Layering, like all architectural structures, reflects a division of the software into units. In this case, the units are layers; each layer represents a virtual machine. A virtual machine is a collection of software that together provides a cohesive set of services that other software can utilize without knowing how those services are implemented." Documenting Architectural Layers
Layers are design-time partitions of software into cohesive units. One goal of layering is to make an application more comprehensable and therefore easier to construct and maintain. Another is to isolate frequent changes to a single layer, if possible. The interaction between layers is confined to well-defined interfaces, making it possible to reuse the components in different settings.
| user-interface layer | views |
| presentation layer | presenters |
| abstraction layer | models |
| persistence layer | database |
The AP framework is a four-layer architecture in which two layers (presentation and abstraction) make up the actual framework, and two additional layers (user-interface and persistence) are essentially fixed, black-box implementations from outside the framework. Eventually the user-interface layer is to be a selected third-party GUI toolkit, but in this study it is merely an idealization of such. The persistence layer consists of the basic PyPerSyst implementation (unmodified, although suggestions for improvements may be offered).
Individual elements from the user-interface layer are called views, and elements from the abstraction layer are models. We generally use the term presenters when referring to elements from the presentation layer, but in certain situations it may be more accurate to call some of them controllers. Finally, we most often refer to the unit of persistence as a database, although at the proper point the term document is introduced for this purpose. Since the persistence layer is PyPerSyst, transactions also play a key role.
In some four-layer architectures the abstraction layer is called the domain model and the presentation layer is called the application model. The domain model, under this terminology, is a collection of conceptual objects from the application domain, and the application model is responsible for much of the application logic, as well as application flow and navigation. By contrast, the AP framework puts much of the application logic back into the abstraction layer. The abstraction layer objects (models) may be said to be behaviorally complete with one exception: they do not know how to display themselves.
|
presentation layer (with user interface) |
|
abstraction layer (with persistence) |
The primary goal of the framework is to facilitate custom application development by making the persistence and user-interface layers as transparent as possible, leaving only the abstraction and presentation layers for the programmer to worry about. The AP framework is also designed to allow the definition of the abstraction layer in relative isolation from the presentation layer. Each is its own virtual machine. It should be possible, in other words, to write and test the abstraction layer for a given application with little or no thought to what the presentation layer is to look like. Moreover, the AP notation arising from this study shall allow the programmer to define the abstraction layer without being familiar with PyPerSyst (at least in any detail) and to define the presentation layer with no knowledge of the underlying GUI tool set.
The presentation layer mediates between the user-interface layer and the abstraction layer. In other words, presenters mediate between views and models.
| Presenter | |||
|
|
A presenter should be thought of a thick wrapper around an appropriate view from the uiGUI tool kit. By thick wrapper we mean that the presenter establishes bidirectional connections between the view and the model, and it may implement additional functionality as well. The technique used here is to make the presenter a subclass of the view that it wraps. The presenter also becomes a wrapper around the associated model, but it does so by holding the model as an attribute.
The abstraction layer mediates between the presentation layer and the persistence layer.
| Transaction | |||
|
The fundamental unit of this mediation is called a transaction. In a transaction, the modified state of a given model is first validated and then used to modify the corresponding state of the database. The model itself is behaviorally complete, but only its essential state need be persistent. The abstraction layer, then, is responsible not only for providing behaviorally complete models, but also for extracting their states such that valid transactions can be formed from them.