• 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

Design implementation Doubt Please tell me the best approach

 
Ranch Hand
Posts: 528
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ranchers,

I have to persist the CRUD operations ,so for this i am using Hibernate and SessionBeans 3.0

Now my doubt is that

I have a DAO layer in form of Hibernate DAO Layer , where all these methods are implemented by the SessioBean 3.0 , Now whether this SessionBean should do the operations itself , or it should call any other layer or another sessionbean to do this operations??

Please tell me the best approach .
waiting for your responses
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It makes sens to have a DAO layer seperate from your EJBs. This way should you ever want to access the DAO functionality from a different application you are not tied to using EJBs.
 
RaviNada Kiran
Ranch Hand
Posts: 528
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your prompt reply .

I think that you suggested me to go this way:

This SessionBean should call any other layer or another sessionbean to do the operations.

correct me if i am wrong here.waiting for your response

 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes.
 
RaviNada Kiran
Ranch Hand
Posts: 528
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jai Ho Paul

Should i use Session Beans or EntityBeans or Normal JavaBeans to perform these DAO implementaions

what you suggest is most best for performance ??
 
Paul Sturrock
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Performance isn't the consideration here, the three you pick do different things.

SessionBeans: you are already accessing this new DAO code via SessionBeans; what does creating more give you?

EntityBeans: these are a legacy technology, and force your DAO logic down an EJB route.

JavaBeans: you are unlikely to be able to write DAO core that adheres to a JavaBean specification.

I recommend you go and read about the DAO Pattern first. Once you've understood that how you write it should be easy enough.
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's exactly what I was going to ask.

I tried to implement the DAO pattern :

One DBFactory + several DAOs like InsertDAO, SelectDAO, UpdateDAO and DeleteDAO. each for every CRUD operation.

I call these DAOs within the methods of a stateless EJB but I'm not sure where to get the DB connection (java.sql.Connection).

there are 2 ways :

Way 1 :


or Way 2:



In way 1 the EJB method handles the transaction (via the SQL Connection). the SQL Connection is only created once (retrieved only once from DB Connection pool) and looks more appropriate to me.
Way 2 is more readable but less portable, because every method retrieves it's own DB connection from pool. if these DAOs would be put in another environment, say a swing app with no connection pool (no JNDI at all) the code of the DAOs must be modified to work (factory.getDBConnection(); method).

another problem of Way 2 is, if the first called DAO method ( insert.insertEmployee(parameter1, parameter2); in the example above) would do it's work, but the second or third method would get a timed-out connection from pool it would raise an exception that would not have occured in Way 1.

I would like to know, is it appropriate here to use the DAO pattern at all ( esp. for CRUD operations) ?
if yes, which way should I use ? Obtaining a SQL connection in every method has a cost, too. but on the other hand I use the benefits of the DAO pattern (more readable, everything is more decoupled, etc.).
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys,

My perspective is to stay away from creating needless layers, factories, etc. In general, I prefer simplified domain-driven design: http://en.wikipedia.org/wiki/Domain-driven_design. In this architectural paradigm, you would have domain objects (JPA entities), services (EJB session beans exposing application services around each domain object) and a repository (a session bean DAO corresponding to all the CRUD operations for a given domain object). This is generally very simple and good enough for a vast majority of applications. To give a concrete example, you would have things like: Employee (JPA entity), EmployeeService (session bean with injected session bean DAO) and EmployeeDao (session bean with injected EntityManager). I even use the Employee object in JSP (or Facelet) pages/JSF pages/backing beans.

Now, there are some folks who claim that DAOs as session beans has performance implications. In my experience, this is a left-over perception issue from EJB 1.x/EJB 2.x. In practice, I have not seen any performance trade-offs. In fact, I prefer that both service tier and persistence tier objects be transactional, thread-safe and pooled (aka EJBs). There are also some folks that question the need of a separate DAO layer given the JPA API: http://www.infoq.com/news/2007/09/jpa-dao. I do not support such a view because JPA still has a lot of things that are very "database"-ish such as JPQL statements.

Hope it helps,
Reza
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic