Data Access Objects (DAOs) :
- can be used in a large percentage of applications - anywhere data storage is required.
- hide all details of data storage from the rest of the application.
- act as an intermediary between your application and the database. They move data back and forth between Java objects and database records.
- allow ripple effects from possible changes to the persistence mechanism to be confined to a specific area.
For simple DAOs, various implementation styles are possible :
Style 1 - instance methods
MessageDAO dao = new MessageDAO();
List<Message> messages = dao.fetchRecentMessages();
This is the recommended style. Create an ordinary object in the usual way, and use its services.
Style 2 - variation on Style 1
List<Message> messages = new MessageDAO().fetchRecentMessages();
The DAO is created and used on the same line. This style seems a bit less legible than Style 1.
Style 3 - static methods
List<Message> messages = MessageDAO.fetchRecentMessages();
Probably the least desirable. One must exercise care that such classes are thread-safe. This issue usually doesn't exist in Styles 1 and 2, if the DAO has no static members, is short-lived, and there is no possibility of sharing data between threads.
Full DAO Design Pattern
It is common to describe Data Access Objects as an extended design pattern. That design pattern centers on allowing wholesale changes to a datastore mechanism - for example, changing from a relational database to using the file system, or some other means of data storage. It is only required when multiple storage mechanisms must coexist.
It must be stressed that most applications do not need the full DAO design pattern
as usually described. Most business applications are deployed with
a very particular database in mind. In such cases, allowing a deployer
to configure various types of datastore seems entirely superfluous. If your application
interacts with only one datastore at a time, then the
full DAO pattern is clearly of dubious benefit.
Rather, implementing each DAO as a single, ordinary class seems more appropriate and effective.
Keep SQL out of code
Minimize ripple effects
Try pseudo-persistence for mock ups