Discussions

EJB design: Entity beans, when to use / when to not ?

  1. Entity beans, when to use / when to not ? (5 messages)

    Hi,

    What would be the decision factors/ questions to answer -
    In desiging a J2EE application should I use Entity beans to map the underlying database or my own JDBC code?

    In other words what would be the cons and pros (both sides of the coin) in using Entity beans to access databases, as compared to writing ones own JDBC code as DAO objects.

    (what I hv found tend to be pro's of Entity beans, no con's)

    rgds
    Jeevan S
  2. I think we as a community have a dilemma with "using Entity beans to access databases". I'm sure a lot of people is stuck with (possibly relational) legacy data and want to make use of it via J2EE technologies. While this leveraging of available data and new technology may seem a good idea, it is not.

    I've been consulting a major bank in Turkey and have experienced the drawbacks of not being able to put down a consistent O2R model on top of an existing relational model. Legacy data keys rarely are not business oriented. They had customer-ids, account numbers and a whole plethora of business oriented primary keys in legacy data. This just is not the base to build an object oriented system on, but, you just cannot ask a bank to migrate the frigging data into an OID connected mesh, can you?

    Anyway, I would advocate the use of third party tools to generate BMP EBs instead of app server features for complex O2R mapping situations.
  3. If u are going to be doing a lot of reads and writes to an entity in the database which integrity is important then use EB's if your DB schema is complex and you are using 1.1 go for BMP's, If you are going to just be doing reads stateless SB's are fine but absract the data layer in to DAO's.

    Babur
  4. imho

    there is one main reasons to make an ejb's: you make a distributed system, where objects in differnt computers need to talk to each other .

    i think entity beans start being usefull if your application needs to be able to let different beans cooperate on different computers, and if you decide not to hide the entity bean behind a session bean.
    If that is not the case, it's most likely overkill to use entity beans: the entity bean would always be accessed from a session bean (facade) on the same computer -> there's no reason to be an ejb (it's never accessed remote). I prefer using a jdo system in stead. There are some jdo's in development, i know of sun's jdo and a jdo called castor.

    I have developped my own jdo, because i like developing low level framework-like things :) (i like it more than spendig days trying to get a jdo running that is still in beta).

    Jdo is a layer that automates persistence, like entity beans cmp do, but my jdo is light because it focusses on performance. The main difference is, that jdo objects are "local", i mean not distributed, all in one virtual machine. Let's say i have a User object (name, password). If it were an entity bean i would have to do a lot of work to make it an entitybean, but maybe all i wanted is just automated persistence, because i know the user object will always be used by my SessionFacade, which runs on the computer where the jdo runs as well (the user never goes to another vm). The performance price for entity bean is high if you only like it for automated persistence. And when you need to relate entity beans, it's quite complicated. In stead i tell my jdo layer: here's a user object, persist it. The layer will look for the user table, compose a sql statement using reflection, and insert the user object.

    This first step is easy. For objects without relationships to other objects it's really easy to make such a jdo layer.
  5. <i think entity beans start being usefull if your application needs to be able to let different beans cooperate on different computers
    >>
    this can also be achieved by RMI objects.
    I think the main use of EJB is the fact that the conatiner manages transaction ,security,pooling etc else you will have to build your own framework for it.

    Do correct me....

  6. I think the main use of EJB is the fact that the conatiner manages transaction ,security,pooling etc else you will have to build your own framework for it.
    <
    true. But isn't it true that you don't need securty at entity bean level (if you don't expose your entities to the outer world)?
    What you need for entities, is easy to achieve and performant persistency.
    The problem with entity beans is, either you get it all, or you get nothing. You can't say: i just would like the cmp, but don't give me the overhead of remote interface and security and transactions.