This page last changed on Dec 07, 2009 by etj.

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.

Proposed architecture

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.

Technical misc stuff

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:

List getResourcesByName(String name, Class clazz);
List getResourcesByNamespace(NamespaceInfo namespace, Class clazz);
List getResourcesByStore(StoreInfo store, Class clazz);

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:

List getResources(Class clazz, Filter optionalFilter);

CatalogDaoSplit.png (image/png)
Document generated by Confluence on May 14, 2014 23:00