The purpose of this article is to demonstrate a solution which magically hide the details of handling the database from programmer. It is called PAT (Persistent Applications Toolkit) and is based on an object-oriented database called Prevayler. It has been designed using aspect-oriented programming (AOP). Furthermore, the article presents some theoretical knowledge which shows the need for building increasingly simple database solutions, along with a brief explanation of the cause of this need: the client.

The Client, the Developer, the Database

Times have come in which when it comes to developing software, simplicity of solutions and the quality and quantity of used resources are the aspects that count the most. Agile methodologies encourage light-weight approach to developing software, emphasising simplicity, the actual need, quality of code, automation and, above all, communication with the customer. Small tasks and short (weekly) release cycles are important, because they reduce the risk of ruining a formerly-working program. Let us remember that the customer and computerisation of his enterprise processes matter the most; after all it is him who pays our employer for development of IT solutions.

At the same time, software engineering is a complicated field. Modern software must be able to communicate with other systems, operate in a plethora of environments and run on many different platforms - thus imposing many non-functional requirements on the software itself. The most important of such requirements is of course persistence of data, i.e. what is commonly achieved by database systems. If programmers used database solutions which require writing smaller amounts of code, they could spend saved time on e.g. trying to gain better understanding of the needs of the customer.

The Data

The data computer programs work on is the most precious. It must survive program shutdowns, server outages or malfunctions of Internet connections. Does the program from Listing 1 answer this need? It implements an operation of adding a new object to the system. It is pure Java, the program is simple and very clear - that's why it is great! Then again, it is completely useless: its termination doesn't cause the state of the myCompany object to be stored.

Listing 1. A program creating an object

 
 
public class AgileApp {
   public static void main() {
      Company myCompany = new Company("Heaven Sp. z o.o.");
      myCompany.add(new Department("Accounting"));
   }
}

In real-world applications we want to create and manage thousands, if not millions, of data entities; they can be counterparts on ink-and-paper documents, user information, bank accounts. This data is created in RAM or loaded into it. Unfortunately, in most cases the amount of this data exceeds the capacity of RAM; even server machines do not (and did not) allow storing all data in memory.

For this very reason we use database systems. They are capable of storing enormous amounts of data on hard discs. As a result, application data has to be constantly moved between memory and discs.

Each of the available database systems possesses its specific API - a set of public functions making it possible to use the system. For example, in order to store the state of the myCompany object in a relational database system (RDBMS), one would have to use the program from Listing 2. This program is also correct - it causes the data to be written - but ugly: enterprise logic of classes: Company and Department is mixed with the issue of data persistence.

Listing 2. A program to store an object (RDBMS)

 
 
public class AgileApp2 {
   public static void main() {
      Company myCompany = new Company("Heaven Sp. z o.o.");
      myCompany.add(new Department("Accounting");
      // the DatabaseModule class conceals details of using SQL and JDBC.
      DatabaseModule.insertStatement("COMPANY", "ID", "NAME", "1", "Heaven Sp. z o.o.");
      DatabaseModule.insertStatement("DEPARTMENTS", "ID", "NAME", "
COMPANY_ID", "100", "Accounting", "1");
   }
}

The Data Layer Problem

Common methods of supporting databases often rely on isolating a special module the purpose of which is to conceal (encapsulate) the complexity of communicating with the database, thus making its handling easier. This module, along with all code fragments handling it, is called the data layer (tier). Implementing enterprise logic, the purpose of which is to manipulate data, one unfortunately has to include the need for regular fetching of data from the database, modifying or deleting it. There are solutions which facilitate this process, one of them being Hibernate. XDoclet automates the process of converting classes to RDBMS tables. The DAO (Data Access Object) model nicely conceals implementation of the data layer.

Nevertheless, one could go much, much further here. Keeping in mind that a class is a fundamental entity of the object world, containing both attributes (data) and methods (enterprise logic), one encounters a question with no given answer: why not just base on a simple object-oriented system architecture, in which the data is stored magically, without any actions on behalf of the programmer? With no additional mapping, with no implementation of special design patterns that require coding additional classes? Why couldn't the program from Listing 1 simply work?