Discussions

EJB design: One session bean per table - good/safe design ?

  1. We are developing a financial application on WebLogic 8.2. We are using CMP.

    For management of different business entity data (Create/Read/Update/Delete - with/without application logic based authorization) we are planning to generate the code (using Velocity, XDoclet) instead of hand coding entity by entity for each module.

    We need to arrive at a template/programming model based on which the code will be generated.

    We are considering the following option -

    * One session bean facade for each module - with CRUD methods in its remote interface for each entity in that module

    * One entity bean (local) for each table - also using CMR where required

    * One session bean (local) for each entity bean - providing access to the CRUD methods of the entity bean.

    * Facade session bean delegates call to local session beans fronting the entity bean


    While this will work, we were wondering whether this approach of

    "number of session beans = number of entity beans = number of tables"

    has disadvantages.

    The advantages of this approach we see are -

    - Easy to generate
    - Easy to understand the genreated code and consequently easy/cheap maintenance

    We are looking for possible disadvantages. For example, does performance get affected with so many session beans ? Would really appreciate any information/pointers towards disadvantages (if any)of such an approach.


    Thanks
    Kingshuk
  2. We are looking for possible disadvantages. For example, does performance get affected with so many session beans ? Would really appreciate any information/pointers towards disadvantages (if any) of such an approach.
    I think the impact on performance would be minimal. Session beans are rarely a major choke point in the application, compared to Entity/Database operations.

    You might have some server management issues, because each Session bean will have its one server configuration, pool size, etc. It will make it more difficult for the server administrator to adjust server performance at run time.

    I don't think that is a good enough reason to abandon this approach though; simplicity of design trumps this kind of issue. This is certainly a widely used pattern.
  3. Hi!

    What is the purpose of local session beans? You could use entity beans' methods for CRUD operations.
  4. If we model an Entity for each table, we might need the join to specify a reference to Entity Bean 2 (from table2 ) from Entity Bean 1 (from table 1). If this is a one-to-one relationship then you could easily place these into the same Entity bean.

    For a one-to-many relationship you could specify a collection of EJB references to Entity Bean 1 inside Entity Bean 2.

    If you're using CMP, this will be very much reliant on the EJB CMP tool that you are using.

    Another possibility is that one of the tables may not map to an entity at all: it may instead map to a 'value object' for eg a Vendor (would be entity) who has many Addresses (each of which would be a value object). The net effect is that your Entity become more coarse grained. You can access a complete Vendor in one shot, it is simpler to construct transactions as you get a chunk of data and
    it allows you to define an optimistic locking mechanism at the Vendor level, so that you can detect when possibly conficting changes are made to any of the Vendor's dependents.

    To avoid the complicated nature of doing joins with Entity beans , you might want to look at the DAO(Data access Objects) route suggested in blueprints. Use the entity beans only for creating and updating records. Avoid them for Retrieve as DAO's improve performance.
  5. Disadvantage:
      1.high burden of management for these session beans. The app server have to manage them, and the administrator have to manage them.

      2.the session beans not necessary to be coupled with data design. Changes of table affect the application tier.


      In my opion, ONE session bean for all tables is enough.