DOA as session bean ?

[Bess Moore]

Hi there

i been really struggle and confuse about the the DAO pattern,

questions:
1. When creating an DAO layer, does those DAOs need to be an session as well?

2. If so, does it not creating too many session beans, ie. session with Bizlogic and session with DAO,
will these affect the EJB container performance?

3. At the moment i have SessionBean with @PersistenceContext call to a DAO,
then the DAO obtained EntityManager by using InitialContext lookup.
Does it mean it that my persistence is not managed?


i am really confuse, your helps is appreciated.

Bess

[deepak adlakha]

I am not sure about your question here.

DAO classes will have only code related to access the persistence layer and nothing else like no business or rule validations .

Where as Session bean have methods which can do business validations on input request and if request is fine, then session bean can call further DAO's.

Making DAO as session means what ?

[Bess Moore]

is better show it in code
-----------in EJB level -----------------------------------------------------------------------------------------
In the EJB3 EntityManager can be get by using @PersistenceContext private EntityManager em;
However if we implementing the DAO pattern, we need to move the EntityManager into DAO level right?
-----------------------------------------

@Stateless
@Remote
@PersistenceContext(name="jndipu",unitName="DB-ejbPU")
public class CategoryModelImpl implements CategoryModelIF {
public CategoryModelImpl() { }
public Category[] getAllCategorys() throws CategoryException {
EAOFactoryManager eaoFactoryMgr = EAOFactoryManager.getEAOFactoryManager(EAOFactoryManager.TOPLINK);
CategoryEAOIF catDAO = eaoFactoryMgr.getCategoryEAOIF();
return catDAO.getAllCategorys();
}

---- in DAO -------------------------------------------------------------------------------------------------------------------------
The DAO is just a plain POJO that obtains EntityManager by InitialContext
---------------------------------------------------------------------------------------
public class CategoryEAOImpl implements CategoryEAOIF{

protected javax.persistence.EntityManager em;

public CategoryEAOImpl(){ }

public Category[] getAllCategorys()throws CategoryException{
em = getEntityManager();
Query query = em.createNativeQuery("SELECT cat_id, cat_name, cat_description, version FROM Category", Category.class);
List categories = query.getResultList();
return (Category[])categories.toArray(new Category[0]);
}
}
--------------------------------------------------------------------------------------------------

In order to get the EntityManager, we Can assign the DAO as a POJO then lookup by using INtialContext or we can assign the DAO as session bean

Here come the questions
1. Which one would you choose?
2. If we Choose to make the DAO as a session bean would it be too many bean in the EJB container
3. BY using InitialContext Lookup we can obtain the EntityManager through JNDI, does it mean it do ContainManage as well?

make sence?

[Cameron Wallace McKenzie]

Your DAOs shouldn't be session beans. Instead, they should be very lightweight components, essentially POJOs, that are invoked by other classes, which might very well be a session bean. So, Session beans very often invoke a DAO, but the DAO itself should be just a simple Java class.

I've got a few tutorials on DAOs on my website. They might be helpful:

Working with DAOs in Hibernate

-Cameron McKenzie

[J J Wright]

I been really struggle and confuse about the the DAO pattern,

OK, first off - why are you using the DAO pattern? The reason I ask, and this seems to be a common area of confusion, is because you already have a ready built, standardised, Domain Store courtesy of the JPA API.

If you have access to a copy of Core J2EE Patterns (2nd Ed) go and take a look at some of the usage scenario examples for Domain Store. It should clear up any doubts your having about how to proceed in this area.

I'm considering writing a brief blog post on this - when I do I'll post a link.

[Hong Anderson]

If you want to call DAO from a servlet, and you're using EJB. Yes, the DAO should be Session Bean to able to use CMT.

[Cameron Wallace McKenzie]

Yes, the DAO should be Session Bean to able to use CMT.

A DAO should never be implemented as a Session Bean. The idea of a DAO is to decouple database access from the design. Making it a Session EJB ties you to an EJB infrastructure. It means if you want to use the same DAOs in a stand-alone application, you'd have to completely re-write your application.

A DAO can be invoked by a Session bean, and the Session bean could use CMT. I'm sure that's what the original poster means. Nobody would ever recommend implementing a DAO as a Session bean.

-Cameron McKenzie

[Cameron Wallace McKenzie]

The reason I ask, and this seems to be a common area of confusion, is because you already have a ready built, standardised, Domain Store courtesy of the JPA API.

The DAO pattern will easily insulate you from the JPA api, thus the point of the DAO pattern.

go and take a look at some of the usage scenario examples for Domain Store

http://www.corej2eepatterns.com/Patterns2ndEd/DomainStore.htm

I often hear the argument that "Just use the JPA Domain Store, you don't need a DAO." That assumes nothing will ever replace the JPA Domain Store. Just like I hear arguments that nothing will ever replace Hibernate...and nothing will ever replace TopLink...and nothing will ever replace JDO....and nothing will ever replace CMP....and nothing will ever replace JDBC...and......

I believe the DAO pattern remains a valid pattern, even with EJB3 and JPA.

Here's a little tutorial I wrote on using DAOs with Hibernate and the JPA API. You can see how well a properly designed DAO implementation, with Session EJBs or anything, can greatly benefit any application that used and implementation of JDBC access.

Advanced Data Access Objects (DAOs) with Hiberante and JPA



-Cameron McKenzie

[J J Wright]

I often hear the argument that "Just use the JPA Domain Store, you don't need a DAO." That assumes nothing will ever replace the JPA Domain Store

My concern is that many applications end up over-engineered,. especially when unnecessary layers do nothing but add complexity. Whether or not the DAO pattern remains valid is a decision that obviously has to be made on an application by application basis.

The point I was try to make, and which was specifically aimed at the confusion outlined by the original poster, was that JPA is an implementation of the Domain Store pattern. As such, it would be beneficial to look at the usage scenarios for that pattern. As the diagram you posted shows, the Application Service uses the Domain Store directly.

As for whether or not access to JPA should be wrapped in a DAO layer. Again that's entirely up to you. My only point would be that JPA is part of the EJB specification, non of the other technologies you mention are. We can therefore safely assume that it will be around for some time to come.

With regards to whether or not a DAO can be implemented as stateless session bean - I don't have a problem with collapsing the service and DAO layers if the opportunity arises. In which case you might rename your DAO-come-service a "Data Service". The Data Service interface is what gets exposed other services. If for some reason JPA does disappear you can always provide another implementation.

Another motivation for encapsulating JPA in a Data Service is simply to facilitate reuse. If you find your self constructing the same query in more than one place then why not encapsulate it in a Data Service. This also gives you the opportunity to throw domain specific exceptions like CustomerNotFoundException.

If so, does it not creating too many session beans, ie. session with Bizlogic and session with DAO, will these affect the EJB container performance?

It shouldn't be an issue. As you know stateless session beans are pooled by the container. I've also seen performing testing stats that show an overhead of 3% for EJB vs POJO calls, which is peanuts when you consider the extra services you get.

Here's a little tutorial I wrote on using DAOs with Hibernate and the JPA API

OK but this doesn't address one of the key issues raised in the original question. Namely, if you implement your DAOs as POJOs, how do get hold of a reference to the current EntityManager. In reality there are a number of work-arounds for this including using interceptors and ThreadLocal variables or the TransactionSynchronizationRegistry (if your app server uses thread pooling). However, if EntityManager was only ever intended for use in POJO DAOs, then why did the EE spec writers bother providing a dependency injection mechanism for session beans?

[Cameron Wallace McKenzie]

My concern is that many applications end up over-engineered,. especially when unnecessary layers do nothing but add complexity.

Amen to that!

You do make some valid points, no doubt about that.

-Cameron McKenzie

[Bess Moore]

First of all, thanks for the reoplies, greatly appreciated

Jonathan Aotearoa wrote:.... if you implement your DAOs as POJOs, how do get hold of a reference to the current EntityManager. ....

By using the InitialContext, i have manage to get hold of the EntityManager, here is the flow:-
CategorySessionBean -> getDAOFactoryManager which return new CategoryDAO --> In CategoryDAO using InitialContext lookup

Jonathan Aotearoa wrote:.... if EntityManager was only ever intended for use in POJO DAOs, then why did the EE spec writers bother providing a dependency injection mechanism for session beans?

Thats wherethe part that really confuse me, because i am not sure whether the DAO in JEE design pattern still valid, or do SUN JAVA need to come out with other design pattern?

Cameron Wallace McKenzie wrote:
Here's a little tutorial I wrote on using DAOs with Hibernate and the JPA API. You can see how well a properly designed DAO implementation, with Session EJBs or anything, can greatly benefit any application that used and implementation of JDBC access.

The book looks interesting and has got a high review in Amazon, Just a quick question about the Book, does it covers the EJB3 as well?

[Cameron Wallace McKenzie]

The question of 'which design patterns are still relevant, and which ones are outdated in JEE5' is a good question. I started a thread on that topic at JavaRanch a while ago. I'm not sure if we came to any conclusions, though:

Are J2EE Design Patterns Now Obsolete?

The Hibernate Made Easy book is just that, Hibernate and JPA. A EJB3 Version should be available early next year.

-Cameron McKenzie

[Jason Marston]

Cameron Wallace McKenzie wrote:

A DAO should never be implemented as a Session Bean. The idea of a DAO is to decouple database access from the design. Making it a Session EJB ties you to an EJB infrastructure. It means if you want to use the same DAOs in a stand-alone application, you'd have to completely re-write your application.

A DAO can be invoked by a Session bean, and the Session bean could use CMT. I'm sure that's what the original poster means. Nobody would ever recommend implementing a DAO as a Session bean.

-Cameron McKenzie

In your article on DAO and Hibernate. You use a Factory to created instances of DAOs specific to an implementation like JPA (I know it was actually Hibernate, but the basic idea is the same). For JPA would you pass the EntityManager into the DAO constructor or handle obtaining the EntityManager within the DAO?

My thoughs on this are that a DAO is for Data Access. Obtaining the EntityManager is not Accessing Data. I think the Factory would obtain the EntityManager and pass it into the DAO, either in the constructor or using a setter after construction. This would of course make it easy to switch from EJB3 to Spring for instance.

Even then. How would you obtain the EntityManager in the Factory? Would you make the factory a service (EJB3) and use injection, or use one of the other techniques such as InitialContext lookups?

Regards,

Jason.

[Jason Marston]

I have been thinking on this issue of implementing DAOs as EJB3 Stateless Session Beans.

I have come to the conclusion that doing this does not impose any serious dependancy on EJB3 into the solution.

Here is my thinking.

The reasons for using EJB3 to implement DAO are:

To inject the EntityManager

To make use of CMT

To make use of the EJB lifecycle

Now, if the instance variable we use to hold the EntityManager can be initialised either via the constructor or via a setter. Then moving to SpringBeans for instance is trivial. If we simply ensure that injected variables can be initialised in some other way as I described. Then there is no need to change the POJOs or Interfaces that are used to implement the DAOs. Spring can also handle transaction boundaries and so on, and of course the lifecycle.

Thus we are not dependant upon EJB3 at all.

Of course the things that would need to change slightly are the classes that depend upon the DAOs. However if we were moving away from EJB3 then to be honest those classes would also be EJB3 Stateless Session Beans and I would apply the same guidelines to them.

Further along the chain. In JSF ManagedBeans. EJB3 Stateless Session Beans are of course injected into them. However once again, with a little configuration using JSF Injection, the (now) Spring Beans can be Injected instead of EJB3.

This leads me to conclude that if you decide on EJB3 for DAOs then you can always change your mind later without having to alter any code or recompile any classes.

BTW: When I say I have thought on this. I actually mean I went back to a project I did about a year ago and verified what I remembered. I used the exact aproach I outlined above to enable me to do JUnit and DBUnit tests without deploying my application to a server. I did several combinations over the life of the project starting with just Spring/OpenJPA and finished with OpenEJB/OpenJPA so I could test dependancy injection properly with an EJB3 implementation that was not embedded in an application server.

[Hong Anderson]

Cameron Wallace McKenzie wrote:

Yes, the DAO should be Session Bean to able to use CMT.

A DAO should never be implemented as a Session Bean. The idea of a DAO is to decouple database access from the design. Making it a Session EJB ties you to an EJB infrastructure. It means if you want to use the same DAOs in a stand-alone application, you'd have to completely re-write your application.

In EJB 3, a Session Bean is just a POJO. We can write a POJO and write a deployment descriptor so the code doesn't tie to EJB.

Actually, regardless of DAO, we could say that all Session Beans will tie to EJB technology if we use Annotations.
But in reality, how often do we develop a Session Bean and want to reuse it in an another application that doesn't use EJB?

[Jason Marston]

Probably more relevent when this certification gets updated to JavaEE 6

However, now there is the idea of a Managed Bean in JavaEE. You get all the lifecycle, injection, interceptor and decorator goddies, but, it is not an EJB. It has scope (request, session, application, converation, and so on). All the nice stuff from EJB that we all wanted from Spring. Managed Beans are NOT EJBS.

So now we have a nice way of managing lifecycle, scope and even alternative implementations in different environments, without any of the moaning about using EJBs.

In addition CDI also has events, and is a big part of how the Bean Validation Framework is able to work in all layers of JavaEE.

Just my opinion, but I expect this to be a significant if small part of the future exams.