Table of Contents
The IOPC 2 library is based on the ideas behind the IOPC library. It implements its features and adds the best from the POLiTe and POLiTe 2 libraries as well. Based on the discussion in the previous chapters IOPC 2 focuses on improvements in the following areas:
Transparent usage - IOPC 2 retrieves description of persistent class metamodel using similar mechanism as IOPC, so no descriptive macros are needed. Though OpenC++ has been replaced by GCCXML due to reasons explained in the section called “Conclusion” and the section called “Obtaining metamodel description”.
Reflection - IOPC 2 gives application developers the access to the metamodel through a simple reflection interface.
O/R mapping - IOPC 2 offers all mapping types supported by the IOPC library plus the ADT mapping as presented in the section called “Database mapping requirements continued”. Persistent objects in POLiTe libraries can be mapped on existing database schemas or read-only databases. IOPC 2 has inherited this feature.
Caching - the POLiTe 2 cache layer has been reused in the IOPC 2 library. IOPC 2 supports all features added to the POLiTe library successor including multithreading support.
Library architecture - IOPC 2 library can be used in several configurations depending on the developers' needs. Database drivers have been separated from the run-time library and now they can be switched without the need of library source code modification.
Database access - Support for Oracle 10g database family.
Removal of obsolete features – the implementation of the IOPC 2 library cuts off all the interfaces that were replaced by their newer and more complex versions. It simplifies the work with the library and its maintainability at the cost of lost of backward compatibility.
In the following sections, we will discuss theoretical aspects of the IOPC 2 implementation - mostly the O/R mapping and transparency of the library usage. Following Chapter 5, Architecture of the IOPC 2 library provides more detailed insight into the library architecture and usage.
As stated earlier, run-time part of the POLiTe, POLiTe 2 or the IOPC libraries consist of one monolithic block. There is no way how to link the application against only a part of the library, it may even be impossible because of the internal library design. One of the goals of the IOPC 2 implementation was to make the run-time part configurable. For example database drivers have become separate shared libraries. Thus the addition of another database driver does not result in the run-time library recompilation; drivers do not need to be part of the library source code - they can be developed separately in independent projects.
Configurability does not concern only the database drivers, but also other parts of the library. The library can be used in the following configurations:
Common services - a configuration that provides only basic services like logging, tracing, thread synchronisation and several other utilities.
Reflection library - a configuration that exposes an interface allowing application developers to use the IOPC 2 reflection capabilities.
Database access library - a configuration that provides basic database access via loaded database drivers. It does not offer any advanced features as object-relational mapping or caching.
Persistence library - a configuration that provides the full functionality of the IOPC 2 library. Its features include object persistence, caching, direct database access, reflection and all other features listed above.
The configurations are ordered by dependency, so the reflection library configuration includes features provided by common services. The database access library configuration provides also features of the reflection library, and - as stated earlier - the persistence library configuration provides features of all other configurations.