At the moment two Catalog implementations exist: CatalogImpl and HibCatalogImpl.
The two classes implements the businness logic, handling data consistency, firing events and so on. Most of this logic is duplicated in the two classes, which is a Bad Thing.
What we need to do is to factor out the common behaviour, putting it in the CatalogImpl.
Then we have to identify the peculiar tasks in order to provide a common interface to run them.
The basic difference between the two catalogs is the way they retrieve/persist data: CatalogImpl uses internal collections to store all the info in memory, while HibCatalogImpl retrieves and store data via Hibernate, using DAOs to access the DB.
On the right you can see the proposed architecture:
- The existing Catalog interface does not need any change.
- The CatalogImpl class will deal with all the consistency logic, namespace defaulting, event triggering, etc. It will access the data via the CatalogDAO interface.
- The CatalogDAO interface, dealing with the bare data. The implementations then may, at their will:
- load the info from memory Collections, and persisting data in memory and on file system as well.
- load and persist data from/to a db.
The HibCatalogImpl already uses a CatalogDAO (interface + implementation) to access its data.
This DAO however provides only basic filtering capabilites, by exposing methods to filter by fixed fields:
According to the idea of offering advanced filtering capabilities (please refer also to the resource pagination proposal), the new DAO should allow for generic filtering, such as: