This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
Hi: I am architecting and coding a J2EE project. I am at the stage where I need to architect the data access layer(DAL) for the application. Can anyone suggest good resources that give design guidelines for the DAL? What are the factors that I need to take care of other than the following:  Connection Pooling  Transaction management Can I do the above 2 using OR mapping tools? How do OR mapping tools and the DAO pattern fit in together? Thanks in advance.
Originally posted by p intelli: What are the factors that I need to take care of other than the following:  Connection Pooling  Transaction management
Other important factors include security constraints; separation of concerns between business logic and persistence logic; efficiency; how to handle queries that process large volumes of data and/or produce aggregates. Connection pooling is taken care of by your application server, provided that you use the standard J2EE mechanism of pulling a DataSource out of JNDI. Transaction management is a business logic concern, not a data access concern (although obviously the two need to agree on how transactions are handled). Three implementations are common.
The business logic is implemented in the EJB tier using session EJBs. In that case, EJB declarative transaction handling is the obvious way to do things. The data access layer does not need to worry about transactions at all, regardless of the technology used: entity EJBs, JDBC, POJOs mapped by an O/R mapper...
The business logic is implemented in an application or a web tier using POJOs. It is responsible for explicitly handling transactions using the mechanism supported by your persistence tier -- for JDBC code, this means acquiring a JDBC Connection and handling the transactions using commit/rollback. This connection will be passed to the data access layer as a method argument or some ThreadLocal variable. Again the data access layer has no responsiblity but it has to use the Connection that the business logic layer gives it. For Hibernate or JDO, this means using the transaction handling mechanisms for those platforms.
The business logic is implemented in an application or a web tier using POJOs, but the application uses an AOP-based framework such as Spring that can model transactions as an aspect of the business objects. This is approach combines many of the advantages of the first solution (declarative transaction handling) with the second (lightweight, efficient, works in an application and the web tier), and has the added advantage of removing all dependence on the persistence mechanism from the business logic layer. The data access layer will acquire connections using framework mechanisms so as to allow it to implement its transaction handling. Spring will integrate out of the box with plain JDBC, Hibernate and JDO, but can be made to integrate with just about anything else.
Although in small and simple projects an O/R mapper may allow you to get away without DAO layer, accessing data directly from the business logic, I do not advocate this in general. DAOs give you the following advantages:
They allow clear separation of concerns between business logic and persistence logic.
They allow the business logic layer to be largely agnostic with regards to the backing store: an RDBMS, an OODBMS, an XML file...
They give you pluggability, allowing you to partially or wholly replace the persistence mechanism as and when needed.
They help testing: you can test data access separately from the business logic, and you can also do a much better job of testing the business logic by plugging in a dummy DAO.
If you're interested in this stuff, read this thread as well. - Peter [ October 15, 2003: Message edited by: Peter den Haan ]