Discussions

EJB design: How bad is entity bean?

  1. How bad is entity bean? (4 messages)

    I'm planning to use entity beans in my applicaiton. However, I've heard all these bad things about entity beans: heavy weight, slow performance, persistence problems, etc etc. How bad is it? Is it not practical at all to use entity beans in real world application? Thanks.

    Threaded Messages (4)

  2. How bad is entity bean?[ Go to top ]

    I'm planning to use entity beans in my applicaiton. However, I've heard all these bad things about entity beans: heavy weight, slow performance, persistence problems, etc etc. How bad is it? Is it not practical at all to use entity beans in real world application? Thanks.
    EJBs may be the right solution, but you should consider the pros and cons. Take a look at: http://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html
  3. How bad is entity bean?[ Go to top ]

    I'm planning to use entity beans in my applicaiton. However, I've heard all these bad things about entity beans: heavy weight, slow performance, persistence problems, etc etc. How bad is it? Is it not practical at all to use entity beans in real world application? Thanks.
    Entity beans can be used effectively in real applications, but there are a few design rules that you must follow. The key rule is this:

    1) The client application should never directly access an Entity Bean. Accessing an entity bean from a remote or non-transactional environment is the origin of most of performance-related problems for Entity beans.

    Given this rule, there are a couple of corollaries that follows:

    2) Use Session Facades as a gateway from your client into your EJBs. See http://java.sun.com/blueprints/patterns/SessionFacade.html.

    3) Use Data Transfer Objects (aka Value Objects) to transfer data between your application layers. See http://java.sun.com/blueprints/patterns/TransferObject.html

    These two patterns entails a lot of additional work and may not be worth the trouble. It depends on the nature of the organization you work for. If you company insists on using only "Standard" technologies from large vendors like IBM, Oracle, Sun or BEA, an EJB-only solution may be your best option.

    If your company is willing to use more lightweight solutions for Open Source groups or smaller vendors, you may find tools like Hibernate or JDO easier to work with than Entity Beans.
  4. How bad is entity bean?[ Go to top ]

    I'm planning to use entity beans in my applicaiton. However, I've heard all these bad things about entity beans: heavy weight, slow performance, persistence problems, etc etc. How bad is it? Is it not practical at all to use entity beans in real world application? Thanks.
    The main question is; do you need them?
    If you work in a clustered, (nested) transactional environment the chances are you actually are one of the few that might need Entity beans. If you are writing a webapp, chances are that you probably won't need EJBs.
    There are ALOT of discussions on the web wether EJBs are good or bad, read them (ignore the fud), decide what your requirements are concerning persitance, choose.

    Some other alternatives:

    - pojo (beans) / DAO
    - Hibernate
    - JDO
    - and the list goes on and on and on.

    In short:

    there is no clear cut answer, it all depends on what you're gonna build, how you're gonna build it and what requirements are there concerning persitance.

    Good luck,

    Barre
  5. How bad is entity bean?[ Go to top ]

    As always it depends... Of course all higher level programming standards, like entity beans, make only sense, if they save you time and money while implementing your application. They will, if you would otherwise have to implement features of EJBs on your own. That features could be transaction handling or database access. If you don't need that features - forget about EJBs.

    So how bad are entity beans? If you use them with the right granularity, they will be not that bad.

    Kind regards,

    Andreas Berg, Triona