Data Access Object Pattern

[Malli Raman]

I have seen that people are using data access objects to implement the business logic and database access strategy. Designers used to say that both are tight integrated and hence they are keeping the business logic in the Data Access Object.

My Question is if we want to separate out the business logic with the database access strategy, then how we will do the transaction for 1) using servlets/EJB/Database or Servlets/POJO's/Database.

For example in the Servlets/POJO/DAO/Database method

try
{
business logic
DAO.insert();
business logic
DAO.select();
business logic
DAO.update();
}
catch(Exception e)
{
do the rollback of above database operations
}

Thanks & Regards,
M.S.Raman

[Malli Raman]

Any Answer please..

Thanks & Regards,
M.S.Raman[/QB]

[Adeel Ansari]

I think DAOs are the mapping of your database instead. Business Logic is somewhere above DAOs. We normally use entity beans, other mapping APIs, or our own custom classes to implement the DAO.

To implement business logic we can use session beans, either stateless or stateful, or a plain normal java classes depends upon the requirement.

[Malli Raman]

I got the answer from my friend saying that if you are using session bean with DAO then the transaction will be taken care by the container. So for any exception the container will rollback the transaction.

If the business logic is implemented by means servlets and normal POJO's then the developer will write the code for the transactions by using the JTS transactions api.

[Adeel Ansari]

Originally posted by Malli Raman:
I got the answer from my friend saying that if you are using session bean with DAO then the transaction will be taken care by the container. So for any exception the container will rollback the transaction.

If the business logic is implemented by means servlets and normal POJO's then the developer will write the code for the transactions by using the JTS transactions api.

No its not like that. this is talking about the CMP and BMP entity beans. We can implement DAO using entity beans. If using BMP you have to write the query, else in CMP container do that for you.

And about implementing business logic by means of servlet is bad. Servlet should be used as a controller, just to manage the request/response mechanism.

[Ken Krebs]

Malli,

From the "Core J2EE Patterns" book:

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

From this, you can see that DAO is an integration pattern that keeps the business layer from knowing too much about the source of the data, freeing it from having to change in response to changes in the data layer.

User interface code like Servlets, Struts Actions, and Web Services or GUI clients should of course be a VERY thin layer above the business services and should rely on the business objects to carry out business logic and not try to do it themselves.

With EJB, the Stateless Session Bean is used to access transactional services of an application server. The ui client calls into the SSB. The SSB in turn calls the actual businees service. With declarative container managed transactions (CMT), the deployment descriptor describes the transactional service that will be applied to the invocation of the business service. Best practice is to avoid putting business logic in the SSB and delegate to a POJO business service so you can test the service without an EJB container.

I would recommend to you to take a look at the Spring framework which allows you to use declarative transaction services without any use of EJB. To see how this works check out Chapter 7 (especially section 7.4) of

The Spring reference documentation. I think you will find it very illuminating and it may save you a lot of time and money.

[Malli Raman]

Thanks Ken Krebs & Adeel.

Hi Adeel,

I agree with you about the point 1, the DAO using the Entity Bean (CMP). I don't think BMP will suit in this case as the purpose of implementing the DAO is to seperate out the database logic to make sure that it is independent and can be replaced by another DAO for different database vendor.

JSP ---> Servlet ---> Session Bean ---> Entity Bean ---> Database

(In the above case core business logic resides in the session bean and the transaction is taken care by the session bean if I am not wrong.

The second point about servlet is that I am not using the EJB's and will like to implement DAO using only normal POJO's.

JSP ---> servlet ---> POJO --> DAO --> Database

( In the second case, I think POJO will implement the business logic and will have to take care transaction if I am not wrong. If so then whether do we have to use the JTS transaction api in POJO?)

Hi Ken Krebs,

Do my second point about the servlet/pojo/dao is correct?
[ January 24, 2005: Message edited by: Malli Raman ]

[Ken Krebs]

Malli,

Transactions should be applied to business objects like POJOs.

A word of clarification. JTS (Java Transaction Service) is the API used by server vendors to supply transaction services. Unless you are writing an application server, you do not need to know anything about it. JTA (Java Transaction API) is the API used by application programmers. If you decide to implement transactions programmatically, this is what you would use in a J2EE environment. J2EE application servers (not webapp containers) are required to implement JTS to provide support for Global Transactions (i.e. transactions that can be used against multiple resources like databases, JMS messaging systems or other systems using JCA Java Connector Architecture). Normally you will also have to use JNDI to get a UserTransaction in this environment.

There are many applications, i.e. ones that use a single transactional resource like a database, that don't need to use JTA or an application server. These services can be obtained directly from the database using a JDBC Connection to commit or rollback programmatically.

Spring provides the ability to specify transactions declaratively in XML configuration files or through metadata attributes. Spring's AOP framework provides the TranasctionProxyFactoryBean to wrap your POJO in transaction handling code to make the process very easy to implement. Spring supports local (using PlatfromTransactionManager) or global tranasctions (using JTATransactionManager) as a simple item you can specify in your configuration file. If you elect to use a global strategy, you will still need a JTA service provider like a full blown application server. If you only use a single database, you can use the local transaction strategy and run your webapp in Tomcat. this allows you to achieve a lot of what EJB has to offer without having to resort to writing and testing EJBs. These transaction strategies can be applied to any of the persistence strategies that Spring supports, JDBC, Hibernate, IBatis SQLMaps, JDO, Apache OJB, and etc. It looks like support for Cayenne and Toplink ORM's is also forthcoming as well as Hibernate3. Even if you don't want to use an ORM, Spring's JDBC support make it ultra simple to write reliable code that doesn't leak connections.

Again I urge you to take a look at the Spring docs chapter 7. There are good examples there that show you how to set up your application to take care of this as well as a good explanation of transaction management in general.

[ January 24, 2005: Message edited by: Ken Krebs ]
[ January 24, 2005: Message edited by: Ken Krebs ]

[Malli Raman]

Thanks Ken.

As I am new to Spring and takes time to read this document. I got basic idea about the transaction.

[Adeel Ansari]

Malli,

In my previous post I am not actually saying something about BMP and CMP. I was just telling you that your friend is talking about these things. Anyways these are out of scope, because you are not gonna use EJBs, as you said. Infact we can implement DAO by using BMP. However, BMP Cons and Pros would be there.

You are right in saying that your business logic resides in plain normal java classes. Moreover, about the JTS, Ken described it well.

Spring framework is really simple and easy to get. Its nicer, easier, lighter than other frameworks like struts. Struts is heavy but somewhat complete and mature framework though. I am not having good relations with struts .

[Andy Grove]

For example Data Access Object (DAO) code, including example code for exposing Data Access Objects as Stateless Session Beans, you can use FireStorm/DAO to generate full DAO code from your database.

There's also an FAQ entry on Data Access Objects and J2EE transactions:

http://www.codefutures.com/products/firestorm/faq/jdbc/transactions.html

[Stan James]

If one day you find the services of the EJB container sound useful - remote calls, security, transactions, MDB, everything but CMP, you could mod your picture:

JSP ---> servlet ---> SessionBean --> POJO --> DAO --> Database

The architecture I'm on now has one SessionBean that acts as a gateway to a whole cloud of POJO services. It has DAO generated from Rose models. There are plenty of choices at that layer!

[Junilu Lacar]

Originally posted by Stan James:

JSP ---> servlet ---> SessionBean --> POJO --> DAO --> Database

This is along the lines of what is suggested in
this article to use a thin EJB layer, right? (also from article: "Business Logic should never be implemented in EJBs.")