Empire-db » The Empire DAO-Pattern Download

Extending the pattern

Most business applications require access to data that is available from persistent storage and still SQL based relational database management systems (RDBMS) are the most popular type of storage. Access to relational database systems has been made available in Java through the JDBC interface for which all major database vendors provide an implementation. Although JDBC is simple to use on a low level, a lot of hand work is required to efficiently manage data transfer from and to business objects.

Over the years several components have evolved, which extend JDBC in order to simplify data transfer and handling as well as making code independent from the underlying database system's SQL dialect. For the basic principle by which such persistence solutions may work, Sun has defined a pattern that describes how to use a Data Access Object (DAO) to abstract and encapsulate all access to the data source: the Data Access Object (DAO) pattern.

However, the DAO pattern, as well as most of the popular persistence components such as Hibernate, only focuses on data. But we think that in most cases only about 5 to 10% of all entity attributes are required for the implementation of application logic. The rest is merely transferred from the database to the client – e.g. a user interface - and vice versa.
On the other hand, metadata like e.g. value precision, maximum field size or whether a field is mandatory or not, is often necessary for data display, input and validation. Without metadata management such information is usually split and repeated across all application layers. With the provision of metadata these redundancies are reduced which in turn simplifies development and reduces the amount of testing required.

Empire-db has been designed from ground up to deal with data and metadata. For metadata support Empire-db extends the traditional Data Access Object (DAO) pattern introducing a new Data Info Object (DIO). The DIO is a container for all metadata related to a particular entity attribute. Special support has been added for common data model and some view specific metadata attributes but you may also add your own.

This is what Empire-db’s extended DAO pattern looks like:

Apart from the Data Info Object there are two more noticeable differences to classic DAO pattern:

  1. Empire-db works with dynamic rather than static JavaBeans.
    Dynamic beans do not have a getter and setter for every single property like normal JavaBeans. Instead one generic getter and setter is used which takes the desired field as a parameter. In order to be type-safe Empire-db uses a column object reference instead of a string to address the requested attribute.
    As an advantage it is not necessary to change the entity bean when adding new attributes in the data model and you may easily override the getter and setter for generic processing.
  2. The Empire-db Data Access Object only uses the data objects and does not create them.
    The idea is that you may extend your data objects and implement entity specific logic. So instead of transferring and copying all data fields to your business objects you may as well use them directly in or as your business objects.