Again: Entity Beans vs. Hibernate


EJB design: Again: Entity Beans vs. Hibernate

  1. Again: Entity Beans vs. Hibernate (2 messages)

    Quite recently we finished an EJB project where we started with Entity Beans (2.1) and ended with a mixture of Entity Beans and Hibernate (for fast and dynamic searching but not for inserting or updating data).

    Now we are at the beginning of a new project and we wonder, if we should keep this hybrid architecture (Entity Beans for writing and Hibernate for searching) or if we should move to pure Hibernate.

    Any thoughts and experiences are welcome.


    Threaded Messages (2)

  2. Right now I found the following list of advantages and disadvantages.

    - Hibernate Beans are easier to implement since you don't need any interface coding.
    - Queries can be dynamic and perform faster (at least on WebLogic and JBoss)
    - Hibernate offers a more object-oriented approach. You can map is-a relationships as subclasses.
    - For data transfer you can use Hibernate Beans as DTOs if you want (and if it's applicable). You can even fill 'custom' DTOs with query results just with one line of code using the select-new construct.

    - Hibernate Beans are not automatically 'locked' for others while used during a transaction. This can lead to inconsistent data when more clients concurrently modify the same data.

    Any more?
  3. joins[ Go to top ]


    Is there any limitations on the number of joins you can have in query?