EJB design: EJB and OOAD

  1. EJB and OOAD (2 messages)

    please help me clear this doubt.

    I always think OOAD is all about grouping related data and behaviours together into a domain class.

    but as i begin to read the book Mastering EJB II, i realize that EJB encourages us to use Session bean for actions and Entity bean for data... isn't it "against" OOAD??

    pls clarify me.. a million thanks.

    Threaded Messages (2)

  2. EJB and OOAD[ Go to top ]

    EJB, or at least some of the common patterns used in it's context, encourages seperation of business logic and data. Business logic is logic that operates on data, but is not inherent to the data. If you attach this logic to the data, you wind up writing entity beans that can only be used in a single application. Whenever a new application arrises that uses the data, it will require making changes to the data itself (i.e, the entity bean representing the data). To prevent dependence, business logic can be placed in session beans. However, operations that are "inherent" to the data, like withdrawing money from an account, should be placed in the entity bean. This is very similar to the "controller/model" divide used in MVC architecture, if you are familiar with these terms.

  3. EJB and OOAD[ Go to top ]

    " isn't it "against" OOAD?? "

    it's not "against", it's more like "has nothing to do" :)

    EJB is about component, not objects. Objects in EJB are just supporting component based design.

    Look at how inheritance is supported in EJB. It's not supported at all, in contrast to JDO, for instance. Suppose, you have the Catalog with Items. The you want to build your object hierarchy Shoes, Books, Food etc. Do you think this will work with EJB? No way. Because of the way PrimaryKey class is used, to can't really model your domain with objects. Because EJB is NOT about OOAD, it's about components.

    Another thing is that OO is nice to model the world with objects and their behaviours. But it doesn't mean that it's the only way to express the business domain. There are different ways to do it. For example workflows. Why to tie every method to a particular object? Why a method doesn't deserve its own abstraction? So, session EJBs may be used to model such methods, which don't belong to particular objects. In reality, there are more practical reasons for Session beans - Entity beans are very "heavy" objects, if you implement everything in OOAD style, then your application will die running out of power.