• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DOA as session bean ?

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 325
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 254
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 254
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 1936
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Greenhorn
    Posts: 11
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic