Entity Bean Design Issue

Discussions

EJB design: Entity Bean Design Issue

  1. Entity Bean Design Issue (4 messages)

    Hi Guys,

    We have a database with many tables(say 200) then does it make sense to model all the tables as entity beans such that:

    1. Master tables are made read only entity beans using local interface.
    2. Rest all are transaction entity beans.
    3. Generate all the beans using any code generation tool, say middlegen.

    Also, as the project is in design phase so I can merge (and follow above 3 steps) many tables to one but it may violate some of the db design protocols. I am not sure if that's the recommended way or not.

    Please comment.
    NP

    Threaded Messages (4)

  2. Entity Bean Design Issue[ Go to top ]

    Hello neeraj.

    Suggested Approach:
    1. First of all decide do you require EJB or not?
    if yes then..
    You have 3 options for data access in j2ee.
    1. CMP
    2. BMP
    3. Pure JDBC calls.
    4th is JDO but its still in rudimentary stage in my opinion.

    Now your 200 tables may be mapped to N entity beans where N<=200 or N>200.There is no correlation as such between no.of.tables and no.of.entities
    Its upto us to design it.thats it.
    Guidlines:
    1. Use CMP+CMR as much as possibble.
    2. Use BMP for complex nested quries not supported by CMP.
    3. Use Direct JDBC for paging,general search etc.

    4. Shield your data technology using DAO pattern.Refer Floyd book.
    basically your business tier will never know whether you used CMP/BMP/Pure JDBC or not.DAO will encapuslate these stuff.

    Alternative to Entity:
    ObjectToRelationMapping tool.Hibernate is a spearing ahead in the race.
    This you must study..

    Alternative to Middlegen:
    1. Xdoclet
    2. AndroMDA..this is a great tool that genreates code from the Design Diagrams.!!and its free. http://www.andromda.org. It internally uses Xdoclet.

    hope this is helpfull
  3. Entity Bean Design Issue[ Go to top ]

    Thanks for the reply.

    We are porting(no JCA) an existing application from a legacy system to j2ee. We need to have high concurrency & transaction control + role based security. Also, we don't want to put much effort in doing the same, so we thought of generating the entity beans of all the tables and fine tune them by using the best practices.

    a. We will exploiting the CMP + CMR based approach. Infact, the code generator handles the both cmp & cmr generation.
    b. Simple search are done using direct finders.
    c. Complex(spanning multiple entities ) search, we will be using the direct jdbc calls.
    d. We don't have time to write complex code.

    If I follow the above approach, to me it seems number of entities = number of tables. Is any thing wrong with the above reasoning ?
  4. Entity Bean Design Issue[ Go to top ]

    Also look at the design patterns, which will suggest you how to structure yr beans,in some cases you might need BMP/CMP for a corresponding table, as you will be using the Stateless and Stateful Beans as well.
    Classic example is authentication and its details.
    For role based sescurity have a look at JAAS.

    http://java.sun.com/blueprints/corej2eepatterns/index.html

    htpp://www.tusc.com.au/tutorial/html/index.html


    Cheers...
    Vishal.
  5. Entity Bean Design Issue[ Go to top ]

    We are porting(no JCA) an existing application from a legacy system to j2ee. We need to have high concurrency & transaction control + role based security. Also, we don't want to put much effort in doing the same, so we thought of generating the entity beans of all the tables and fine tune them by using the best practices.

    >
    I think its worth giving time to Prepare Domain Object Model first.
    Then ask your self whether a particular Object needs to be represend through CMP/BMP or not..Honestly code-generated does not mean be best...Entity Beans are cached.so those information that will be SHARED across user-base gets high priority to be realized as CMP..otherwise a User Specific information better be avoided as Entity...If you follow Session Facade pattern then you get Transactional Environment...Still for CRITICLE Information [For e.g . AccounBalance]better be modeled as Entity..


    > a. We will exploiting the CMP + CMR based approach. Infact, the code generator handles the both cmp & cmr generation.
    OK
    > b. Simple search are done using direct finders.
    OK
    > c. Complex(spanning multiple entities ) search, we will be using the direct jdbc calls.
    OK
    > d. We don't have time to write complex code.
    But do invest time to think before you write a code..its never a complex code with EJB world.
    >
    > If I follow the above approach, to me it seems number of entities = number of tables. Is any thing wrong with the above reasoning ?
    Hybrid Approach combining following is best i think:

    [A]Right Candidates for Entity:
    1. Shared Information
    2. Criticle Information

    [B]DirectJDBC/StoredProcedure
    1. Search
    2. Bulk Operation
    3. User Specific Information for e.g. UserProfile
    4. Other

    AND USE DAO to shield A and B from session beans.
    Secondly Transaction is Required but not always...meaning you can divide services in 2 categories
    1.Tx-Criticle
    2.Not criticle

    You can configure EJB settings accordingly..Tx if enabled affects performance..