|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||||
See:
Description
| Interface Summary | |
| DAO | This interface defines the methods available from a Data Access Object (DAO) implementation. |
| DAOSource | This interface defines the functionality usually provided by a specific data source, eg Castor, oracle etc. |
| Class Summary | |
| AbstractSequenceManager | |
| DAOFactory | This class is a factory for providing data sources from which a data source connection can be obtained. |
| IntactRowReaderImpl | Row Reader class specific to Intact. |
| ObjectBridgeDAO | This class provides an ObjectBridge-specific Data Access Object, which effectively wraps up an ObjectBridge broker object. |
| ObjectBridgeDAOSource | This class effectively wraps an ObjectBridge broker factory instance and abstracts away the details of the ObjectBridge creation mechanism. |
| ObjectSearch | This class contains methods for performing specific object searches for particular intact object types, based on an object's id or name. |
| OracleSequenceManager | This sequence manager accesses a database sequence object to get the next unique id, leaving the management of the sequence to the database. |
| PostgresSequenceManager | This sequence manager accesses a database sequence object to get the next unique id, leaving the management of the sequence to the database. |
| Exception Summary | |
| CreateException | Exception class to provide more meaningful error messages. |
| DataSourceException | Custom exception class to handle errors occurring with eg opening/closing a connection to a data source. |
| SearchException | Exception class to provide more meaningful error messages. |
| TransactionException | Specific exception class for handling transaction errors that may be thrown from a DAO. |
| UpdateException | Exception class to provide more meaningful error messages. |
This package provides a persistence capability for intact. Specifically interfaces are avaialable which allow for creation and use of abstract data sources for the creation and search of intact objects within a persistence storage mechanism.
Whilst the interfaces allow for the option of changing the underlying persistence technology, at present intact uses the OJB object-relational mapping tool to provide an object view of a backend oracle database. The OJB interface is hidden from users of the intact persistence package, but the package contains both the technology-independent classes and also the OJB-specific implementations. (Please note the change of underlying persistence technology: OJB was chosen to replace Castor mainly for performance, documentation and extensibility reasons.).
The package contains the following groups of classes and interfaces:
DAOFactory class, which provides
a single point of contact for obtaining a particular data source. For web-based applications, the data source to be
returned by this factory could be specified within a servlet configuration parameter, defined in the
web.xml file of the webapps directory. Typically this would be the full
classname of a technology specific implementation of the DAOSource interface.
Currently intact uses the OJB-specific ObjectBridgeDAOSource implementation, although
this can be changed easily if required. Once a client has obtained a reference to the
data source implementation, it is possible to then use it in order to access the persistence
functionality. Alternatively a seperate helper class may be used (as is the case for intact) which
encapsulates all persistence layer access.
The data source itself is initialised via a collection of configuration files, which are passed
to it after its initial construction. For OJB, this is a single file called repository.xml,
which defines the class-to-table mappings. In the case of castor, these are database description
and mapping files, along with the database name. Once intitialised it is then ready to provide
clients with connections to the persistent storage.
Use of OJB as the persistence technology requires no further information, unlike Castor.
DAO interface. This interface defines
a number of the more common operations provided by most persistence technologies - for example
creating and searching for objects, transaction management and so on. It is therefore possible
for clients of the DAO interface to manage their own transactions, but in cases
where this would not be appropriate (for example in a web environment), implementations of the
interface should manage transactions themselves, and therefore removing the need for clients
to worry about transactions.
The ObjectBridgeDAO class provides an OJB-specific implementation
of the DAO interface, utilising both the PersistenceBroker and ODMG APIs provided by OJB (typically
if transaction management and locking are required ODMG is used, but for straight query the PersistenceBroker
API is used to avoid the transactional overhead of ODMG). OJB provides a more felxible method of query
to Castor, and is better documented. Furthermore OJB is under active development via Apache, whereas
Castor's object-relational mapping solution (JDO, *not* to be confused with the Java Data Object standard)
is not. The OJB approach to lazy data loading is centred around the proxy concept, whereby objects may
hold proxies to referenced objects. Full objects are then materialised on demand via the proxies. Also
OJB has the concept of a Collection proxy, which provides a single proxy for Collection references rather
thain requiring the maintenance of a Collection of individual proxy instances (which would be similar
to a Castor-based approach). Furthermore objects along with their proxies are not bound to a transaction
as they are for Castor. This makes objects retrieved available "as is" within an application, without having
to maintain the transaction to keep the object references alive. At present it appears that OJB provides
a superior object-relational solution to Castor - however Castor is the preferred solution for XML
marshalling applications, since OJB does not provide such functionality.
Previously a CastorDAO class implemented a castor-specific solution. This has now been replaced with an OJB solution for a number of reasons, chiefly concerned with the lazy loading strategy, code complexity, lack of useful documentation and low level of development activity for Castor JDO.
|
|||||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||||