Discussions

EJB design: When to go for entity beans

  1. When to go for entity beans (2 messages)

    1. What are the criteria for deciding to go for entity bean. If data caching is the only reason then does that mean I do not have to use it for data I do not want to cache.

    2. Does it make sense to use EJB for static table lookups. If so will there be any problem if I use JDBC for maintaining these tables?

    3. If I use CMP for my entire database, I cannot have a denormalized data model, but does CMP do away with the need for de-normalizing?

    (All my reference to entity bean is for CMP entity bean, BMP is available only for legacy and I dont plan to use it)

    Threaded Messages (2)

  2. When to go for entity beans[ Go to top ]

    1. What are the criteria for deciding to go for entity bean. If data caching is the only reason then does that mean I do not have to use it for data I do not want to cache.


    The criteria for choosing entity beans is pretty difficult. You need to consider database schema, transaction, useage and performance characteristics. I wouldn't bother with caching as a criteria as caching is easy to implement elsewhere (especially for reference data). In particular:

    - Does your database schema match the entity model neatly. I.e. can you map each entity to one row of one table. If you can't then you may need to consider JDBC or an O/R mapping solution.
    - Does your data need to be transactional? Entity beans are fine for transactional usage but can have an unnecessary overhead for read-mostly and non-transactional data
    - Do your use cases dictate only working with a small number of entities at any one time? Entity beans are great where each use case only works with a handful of beans. They are a very poor choice if you need to access hundereds or thousands of bean instances at the same time.


    > 2. Does it make sense to use EJB for static table lookups. If so will there be any problem if I use JDBC for maintaining these tables?

    Many people avoid entity beans for static table lookups. Where the lookup is for a tiny number of items the effort in writing the bean is a waste. For large lookups the performance hit can be huge. Personally I'd suggest using JDBC for reference data and chaching the data in memory in the layer where it will be used from.


    > 3. If I use CMP for my entire database, I cannot have a denormalized data model, but does CMP do away with the need for de-normalizing?

    This is a major problem/weakness of CMP. Each entity bean can only map to one row in one table. If you have full control of the database schema or the schema maps nicely to your beans then CMP is an option. If this is not the case then I'd recommend normalising and tuning your database properly and using a different persistence strategy such as JDBC, JDO or an O/R mapping tool. Database schemas are normally more pervasive over time than the applications built on them, thus getting a well tuned database willprobably give you much more success in the long term.
  3. When to go for entity beans[ Go to top ]

    Actually, modern CMP implementations can do better than "one Entity = one table". Any CMP implementation can read a subset of a table, and most allow you to read data from multiple tables using simple joins. Basically, any join that could be used to define an updatable database View can probably also be used to define a CMP entity bean. Chris's analysis is still basically correct, though.

    The dividing line I use for when to use Entity beans or not has to do with whether a particular operation is update-intensive or read-intensive. Entity EJB are good for CRUD-type operations that must be incorporated into transactions. I use JDBC for read operations, especially complex queries so that the query can be better optimized.

    All of this is assuming I decide to use EJB at all. Most of the time I use a more lightweight, JavaBean-based persistence framework.