File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Entity v/s Session Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Entity v/s Session " Watch "Entity v/s Session " New topic
Author

Entity v/s Session

Suneesh Raman
Ranch Hand

Joined: Jun 13, 2002
Posts: 42
Which is the better approach ? Accessing the database from a stateless session bean or using the entity bean . say I am developing a user management module for a portal and the user creation is not a frequently occuring action . Need I use to stateless session bean and call the database or entity ?

Thanks
Suneesh VR
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
Use Hibernate. www.hibernate.org


James Carman, President<br />Carman Consulting, Inc.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by James Carman:
Use Hibernate. www.hibernate.org




Why Hibernate ?? Most of the time, for a simple DB access, an Entity CMP is easy and efficient


/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Arul Prasad
Ranch Hand

Joined: Jan 20, 2005
Posts: 57
hi

Normally we can use session facade Design Pattern (i.e) the entity Bean will acess the DB and form the SB(stateless session Bean) we can acess the Entity Bean....

the advantage of this pattern is to reduce the network traffic....

Note:

we can use the DB With SB if need to execute the complex quries for the Report generation... etc

It is all depend on the requirement and the usage



With Regards<br />Arul
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


Why Hibernate ?? Most of the time, for a simple DB access, an Entity CMP is easy and efficient

Jean-Louis, I've never heard Entity Beans described as "easy" or "efficient". OK, we could have an arguement over the easy part - whats easy for one is unecessarily complex to another. Efficiency though, I will take exception to. If by efficiency you mean application performance, well Entity Beans have very well documented performance shortcomings, hence the emergence of such J2EE patterns as "JDBC For Read". Alternatively, if by efficiency you mean development efficiency, again comparing a EJB container bound, vendor specific, heavy weight ORM solution like Entity Beans with a lightweight, platform independent solution which doesn't even need an EJB container is a bit of a non-starter.

In answer to Suneesh VR's question, I'd say use either JDBC (via a DAO layer) directly from your sessions beans, or use a lightweight ORM solution like Hibernate, again from your sessions beans. I'd also say I'd never consider Entity Beans. I've listed these reason before, but I dislike Entity Beans so much I don't mind listing them again:
  • They are not a portable solution. Despite Sun's claims to the contrary, anyone who has had to move an ORM layer written using Entity beans from one container to another will probably agree with me that it is a non-trivial task. Hibernate on the other hand, works with any container without any configuration changes.
  • You can't pass them to the client, so they require anti-patterns like DTOs.
  • You can only access them through Session Beans, which for many applications is not a good choice.
  • EJB-QL is a sub-set of SQL. SQL is the absolute minimum of what DBs need in terms of a workable Query language, which makes EJB-QL less than sufficient. You can end up accessing the DB in an inefficient way as a result of EJB-QL's limitations. Hibernate's HQL is much richer, and allows direct SQL queries if they are needed.
  • Entity Beans carry the baggage of container provided sevices with them. So you can include things like security in your configuration of an Entity Bean. Given you can only access Entity Beans via Sessions Beans, where security can also be defined, why do you need to burdern an Entity Bean with a consideration which is not really the domain or the ORM layer?
  • Entity Beans are designed round a single entity CRUD operations. Most J2EE applications need lots of DB operations which use large, read-only result sets, something which offers cripplingly poor performance.
  • Entity Beans force a 1-1 mapping between the object and the entity. Which quite often results in unnatural ER or OO models (depending on whether the DBA or the Developer wins that arguement).


  • [ February 11, 2005: Message edited by: Paul Sturrock ]

    JavaRanch FAQ HowToAskQuestionsOnJavaRanch
    Arul Prasad
    Ranch Hand

    Joined: Jan 20, 2005
    Posts: 57
    hi Paul Sturrock



    You can only access them through Session Beans, which for many applications is not a good choice.


    Why it is not a Good choice For many Applications???
    Paul Sturrock
    Bartender

    Joined: Apr 14, 2004
    Posts: 10336

    EJBs are only a good choice for large, distributed, enterprise applications. If your application is not this, then EJBs don't really offer much that is helpful - you may very well be better off with a Servlet based app. for example. If your ORM layer is provided by Entity Beans though, you have an implicit requirement for EJBs.
    [ February 11, 2005: Message edited by: Paul Sturrock ]
    James Carman
    Ranch Hand

    Joined: Feb 20, 2001
    Posts: 580
    Originally posted by Jean-Louis Marechaux:




    Why Hibernate ?? Most of the time, for a simple DB access, an Entity CMP is easy and efficient


    Actually, for SIMPLE database access, it's easier to just do JDBC than it is to use an Entity CMP.
    Arul Prasad
    Ranch Hand

    Joined: Jan 20, 2005
    Posts: 57
    hi Paul Sturrock

    thank u nice explanation .....

    i have got the reason ....
    JeanLouis Marechaux
    Ranch Hand

    Joined: Nov 12, 2001
    Posts: 906
    Ok, I won't start a debate here around entity beans.

    I agree with some of your arguments anyway.
    But if you read my post again (I probably misexplained my point) I was just saying that Entity bean can be a good solution depending on your need.

    The question was about users creation. I imagined a simple DB schema , maybe just one table. According to Suneesh, user creation is not really frequent (no performance issue here, do we agree ?)
    So yes, I do believe a CMP could do the job.

    For any more complexe DB issue, I would have considered Session BMP + DAO.

    Of course, there are also zillion of other way to do it. A DotNet Framework, a plain JDBC standalone application, a DataWindow using PowerBuilder....

    But we are in a J2EE and EJB forum here.....
    [ February 11, 2005: Message edited by: Jean-Louis Marechaux ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Entity v/s Session