Any Data Access Pattern for accessing data across subsystems ?

Discussions

EJB design: Any Data Access Pattern for accessing data across subsystems ?

  1. Hi All,

    I'm looking for a design pattern for accessing data across multiple subsystems.

    To elaborate -

    1. Let us assume that there are 3 functionaly independent subsystems in a system being designed using EJBs and POJO for data access.
    2. The interaction happens between these subsystems through messages at the business layer of each subsystem.
    In this way no subsystem accesses the table(s) of other subsystem directly.
    3. However, for performance optimization, it might be needed that for certain cases one subsystem need to access tables of other subsystems through JOINs.

    In this situation I'll like to know if there is any specific pattern used for implementing a performance trade off described in point 3 ?

    My aim is to achieve the above mentioned performance goal as well as retaining the modularity of the subsystems as much as possible.

    Any pointer/insight/information will be really appreciated.

    Regards,
    Sourav
  2. Try using the (more or less standard) Data Access Object pattern. For each class in the system, define a Data Access Object class that controls how that data is loaded and saved:
    public interface DAO {
      public void save(Object o) throws DAOException;
      public void remove(Object o) throws DAOException;
      public Object[] find(Object primaryKey) throws DAOException;
      public Object[] load(String queryId, Object[] parameters) throws DAOException;
    }

    public class DAOFactory {
      public static DAO getDAO(Class class) {
        // Retrieve the DAO for the specified class ...
      }
    }

    public class ExampleDAO implements DAO {
      // SQL logic for loading/saving Example class hidden here.
    }

    // In your business layer code
    ExampleDAO dao = (ExampleDAO) DAOFactory.getDAO(Example.class);
    Example example = dao.find(primaryKey);
    // Make some changes in the example object
    dao.save(example);
    All your SQL logic should be hidden inside your DAO. Your business objects should expose no information about how they related to the database. Therefore, you can optimize your SQL however you like without breaking the isolate of your subsystem's Java code.

    For a detailed discussion see Martin Fowler's Patterns of Enterprise Architecture book or Data Access Object in Sun's J2EE Blueprints.
  3. Hi Paul,

    Thaks for your input.

    However, in my problem I'm assuming that DAOs are already being used for abstracting the data access mechanism from the business object layer. Actually I'm trying to achieve more than that. I'm trying to design a subsystem which will can be deployed separately together with its data access layer.

    Regards,
    Sourav
  4. Actually I'm trying to achieve more than that. I'm trying to design a subsystem which will can be deployed separately together with its data access layer.
    I am not sure I follow ... do you mean that you want Subsystems A, B and C, where is possible to install all three or just Subsystem B by itself?

    If that is the case ... will the separate installations share the same database, or will you use different databases (and therefore different sets of tables)?

    It seems to me you can handle most of the issues through configuration: If Subsystem B is installed with Substem C and A, use the optimized query, otherwise use a fallback query that does not depend on the other subsystem.