The basic structure of a Ubik application is shown below:
The current implementation allows for the separation of
client, server and database, however only one server may be run. Plans for
the future include the separation of the messaging server so that multiple
server machines can be deployed.
Domain Model & Data Mapping
Ubik uses the most abstracted form of business logic
representation, where business objects are decoupled from the database and an
additional layer is used to load and save them to specific tables (c.f. the
Ruby on Rails persistence architecture called 'Active Record,' where the
business objects represent a specific table row.)
Ubik maintains a single instance of each persistent object
within a session. This is done by tracking the 'identity' of the object through
a cache, and ensuring that all requests for the object with a specific identity
retrieve the same concrete instance. Identity Object prevents data aliasing
problems that result when multiple pieces of code update the same 'logical'
object within a transaction through separately-loaded instances, resulting in
Nearly all code is written client-side in business objects
(the exception is described in Server Tasks below.)
A Session is a mutually-consistent subset of the complete
persistent business model that is manipulated independently of other sessions.
The concept is sometimes called an Object Space.
The Select() and SelectOne() methods on Session are the
means by which persistent objects can be retrieved from the database.
BeginTransaction() is the other key method on Session,
allowing for the control of object-level transactions.
Individual is the base class of all business objects. It
uses custom classes for persistent properties that allow it to be registered as
dirty when changes are made.