Discussions

EJB design: What Good are Entity Beans?

  1. What Good are Entity Beans? (4 messages)

    I am fairly new to EJB and am still trying to understand whether I should use Entity Beans in my project. I am currently using Entity Beans for inserting and updating data, but am bypassing the Entity Bean layer when querying data (through a set of "data command beans"). The clients are not exposed to the domain model and thus see only the Session Beans and Data Transfer Objects. Does this architecture make any sense? Am I losing any caching benefits that Entity Beans might provide? Am I less transactionally secure? Any pointers would be greatly appreciated.

    Threaded Messages (4)

  2. Hi
    I felt by answering your question in brief you may not get the real essence of EJB. At the same time its not necessary to use EJB. Even servlets or servlets+jsp or servlets+jsp +jb can do everything for you.

    I would advice you to have a quick read of the following:

    * Java Blue Prints
    http://java.sun.com/blueprints/guidelines/designing_enterprise_appplications

    * Mastering EJB by Ed Roman
    http://www.theserviside.com/books/masteringEJB/

    Hope you would get most of the answers from them.

    Let me know if it was helpful.

    ~ Rao
  3. What Good are Entity Beans?[ Go to top ]

    JaganRao,

    "I would advice you to have a quick read of the following:

    * Mastering EJB by Ed Roman
    http://www.theserverside.com/books/masteringEJB/ "

    If Ed's 2nd edition is like the first, I assure you it IS NOT a quick read. :) Although, an excellent read.







  4. What Good are Entity Beans?[ Go to top ]

    U r so right Mike.... :-).
  5. What Good are Entity Beans?[ Go to top ]

    For most instances u dont need entity beans at all. Simple JDBC retrieval will do.

    About caching benefits, connection pooling is now supported by most of the application servers for jdbc connections too. I think, u r doing the correct thing by using entity beans for updates and not for selects. In fact, u may want to write SQL Stored procedures for all reads/selects from the database. This has the advtg. of changing just the SP code and not the java code (business logic code) everytime the db structure or query changes. The java/servlets/jsp code should just call the stored procs. Also helps reduce network congestion, if the SPs are sophisticated enough.

    Use of entity beans does give u all the benefits of EJBs like transactions, security etc plus, if your data source changes, u need to change just the XML DD.

    So, while entity beans are useful, they may be avoided afte r a careful scrutiny. Also, as u have correctly done, never make the client access entity beans if possible. Use session beans for business logic and entity beans within these session beans. This way, u reduce network traffic because when the session beans use entity beans, network is not involved, it is within the server environment.