rsh-dal overview

So what is rsh-dal anyways? In a nutshell, rsh-dal provides a standard data access toolkit. By programming to the rsh-dal API, a program or application is then insulated from data access implementation details. This means you could use straight JDBC and then move to Hibernate3 without having to change the code in your DAOs. Additionally, the rsh-dal tries to enforce some general principles on its DAS implementations that make building and testing applications much easier.

Implementation Agnostic

In the same way that DAOs insulate your code from the details of storing objects and loading objects, rsh-dal goes one step further to make your DAOs implementation agnostic. Now you can write complicated or business-logic rich DAO calls without having to worry about details like how you are going to store your SQL or whether your code is releasing connections properly.

The above diagram illustrates the goal. You write your DAO to use the standard API of the DataAccessStrategy, and then rely on your configuration to return to you a DAS implementation instance--which may be JDBC, Hibernate3, or whatever. In the end, your code does not care--at all.

The advantage this gives you is that all the "hard work" of trying out one strategy or another is all in the configuration or support classes. You may have to write Handlers to use JDBC or convert SQL files to Hibernate mapping files to go to Hibernate3--but you will usually not need to re-write your DAOs.

The two primary concepts to enable this implmentation agnosticism are the Data Access Layer (or DAL) and the Data Access Strategy (or DAS).

Works With or Without J2EE, With or Without a DataSource

Currently, the DAS implementations provided with rsh-dal will work in or outside a J2EE container without any changes made to the code or the configuration. This is a decided advantage when it comes to unit testing the components of your application. Instead of having to build and deploy the app just to find out some DAO logic is incorrect or some SQL statement is invalid, you can just use a normal unit test from within your IDE or build.

This also applies to DataSources. You can configure the DriverManager and a DataSource, and rsh-dal will choose whichever is appropriate for your situation. So again, you can test components without having to build the entire app and deploy it within some server that has your DataSource declared.

Standard Facilities for JDBC

If you create a standard, DAO-based JDBC app, you need to handle loading SQL from files, managing connections, managing transactions, pulling data out of result sets, and much, much more. Despite all of these tasks being fairly standard and largely the same from app to app, most apps write them from scratch.

Through rsh-dal and its foundational libraries, you get these functions and more for free. So one less thing to implement.