Layering of Transactional Applications, and handling of state
Case being considered:
A single database is in use, by multiple users, possibly concurrently.
The distributed case of multiple databases in use is much
more difficult and should be avoided if reasonably possible. The use of
O-R Mapping is equally valid for the distributed case, but the full
system is more complicated, so for simplicity, not treated here.
1. All persistent state resides in the database. The database is the
handling shared data
safely in face of concurrent access, so we use it fully. Per-user data
(which is unshared) may live outside the database.
2. All interactions with the database data, even read-only access, are
brought about through actions inside transactions.
3. No user interaction (necessarily causing long delay) may occur
transaction because a transaction should be atomic, or nearly so, and
the database may
hold locks to make this true, or if it doesn't, the lack of atomicity
gets worse and worse the longer the transaction lasts..
To make it easier to obey rule 2, the transaction code is usually
organized into methods, so that each
transaction runs completely inside a call to some particular method.
The transactional methods are grouped together to make the service
layer. The collection of method signatures of the transactional methods
defines the Service API. The
user interaction code makes up the presentation layer, which calls into
the service layer as needed to carry out the actions of the app.
We think of the Presentation layer as above the Service layer,
separated by the Service API:
Presentation layer: line-oriented, GUI, or web scripts
Service layer: methods with transaction(s) within them.
Thus UI actions and their huge delays occur strictly in the
presentation layer between
the calls into the
layer. Here is a timeline for one user's execution: starting in
calling into service layer, returning to presentation layer:
Tx>----work with database data----<end Tx>--<return from
The service API defines what the app can do for any presentation layer,
it's a console (line-oriented) app, a local GUI app, a client-server
app, or a web app. One service layer implementation can support many
presentation layers without change except to initial configuration code
Domain objects: changes are done in
layer, treated as read-only in presentation layer
In general, all changes to domain objects should be done in the service
layer, in a transaction, since their data is persistent and "belongs"
to the database. Once domain objects are finalized in the service
layer they can be sent up to the presentation layer for read-only use
there. This is the conservative approach that will work in any O-R
mapping and is used in the pizza app. The current Topping and PizzaSize
objects are supplied via service-layer calls for the order-pizza form,
and the ids of the toppings and size picked by the user are assembled
in the presentation layer and the "makeOrder()" service is called with
them as arguments. In the service layer, the order object is created
and saved. Alternatively, you could imagine creating a new order object
in the presentation layer as a "scratch" copy, not immediately
persistent, filling it in with referenced Topping and PizzaSize objects
(also now just scratch copies, since we are outside of a transaction
here in the presentation layer) and then sending it down to the service
layer in a makeOrder(PizzaOrder) call. However, now the scratch objects
need to be converted to persistent objects, a more complicated and
error-prone operation than simply creating a new one under a
transaction. To keep things simple, the conservative approach is used
everywhere in the pizza app.
In the supplied example, the service layer API is provided as a
singleton stateless object in both Hibernate and EDM
implementations, with essentially the same methods in both cases.
Since transactions run strictly inside service-layer calls, the whole
transactional state is created and destroyed within a call, so nothing
needs to be saved from service call to service call for transactions.
application data is held in the database, and none of it is in the
service layer between transactions. This strategy is called
"session-per-request" strategy in Hibernate language, referring to web
requests, but generalizable to service requests between UI actions in
The presentation layer may hold some data related to the current user
running the app across several calls to the service API.. In the pizza
app, the user has a room number for pizza
delivery that is remembered in the presentation layer across various
calls into the service layer to order a pizza, check if it's done yet,
etc. This is unshared data that does not need to be held in the
database. If the computer running the app crashes, the current room
number is lost for the user, except in web app cases where the
application server persists session data. If more persistence is
needed, per-user data can be kept in the database as well as shared
The Data Access Object (DAO) Layer
As discussed above, the crucial layer boundary is between the
and service layers, to subdivide the work into transaction units that
run between the much longer user interactions. A less important layer
can be set up below the service layer to encapsulate the domain object
access needs of the application. This allows substitution of different
O-R mapping implementations or file-based persistence for some
uses. The pizza project has a DAO layer, with olmost identical methods
in both implementations.