wood burning stoves 2.0*
The moose likes JDBC and the fly likes J2EE Data Access Lyer Design suggestions... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "J2EE Data Access Lyer Design suggestions..." Watch "J2EE Data Access Lyer Design suggestions..." New topic
Author

J2EE Data Access Lyer Design suggestions...

Yan Lee
Ranch Hand

Joined: Sep 15, 2003
Posts: 94
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:
[1] Connection Pooling
[2] 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.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by p intelli:
What are the factors that I need to take care of other than the following:
[1] Connection Pooling
[2] 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 ]
    Yan Lee
    Ranch Hand

    Joined: Sep 15, 2003
    Posts: 94
    Thanks for the response. It was very helpful.
     
    wood burning stoves
     
    subject: J2EE Data Access Lyer Design suggestions...
     
    Similar Threads
    Customzied OR Mapping
    Using Entity Bean with Data Access Layer
    Non J2EE transactional management in Java
    Questions regarding the DAO pattern
    Do we have to hardcode the fields (order, index values) in the client