General Entity Bean design problem


EJB design: General Entity Bean design problem

  1. General Entity Bean design problem (3 messages)

    Hi all,

    I am relatively new to the EJB field and have general design problems concering
    entity beans.
    I heard from various sources that entity beans should just implement the simple get/set methods. Session Beans should offer the business methods. This refers to the Session Facade Pattern. I agree with that, but what happens if you actually do not need complex business methods all the way, e.g. for creating entity beans. Should you write a dummy proxy, which might be extended in the future? What do you do with all the simple get/set methods? Do you also write proxys in case some business logic might be wrapped inside later?
    For me a facade pattern only makes sense if you use it all the way and "forbid" access to the entity bean directly. But if that means you have to write a lot of proxy methods and probably have to introduce value objects, it ends up in a big hassle...
    Don't get me wrong, I think Value Objects are a nice idea, but do you need them with local ejb's (performancewise)? It adds another layer of complexity.

    In fear of "over-designing",


    Threaded Messages (3)

  2. General Entity Bean design problem[ Go to top ]

    I would suggest the following (as I do it myself):
    - use value objects always; I never have getter/setters for properties in the remote interface, I use the value objects instead
    - if entity related business methods only apply to that entity and/or to entirely contained other entities I implement that business method in the entity itself.
    - business methods that span multiple EJB's are implemented in a session bean

    Still, I never allow access to an entity bean from a client directly. So sometimes I have just a delegation method in my session bean, like in the case that the business method is already implemented in the entity ejb. But I've seen that I rarely encounter this situation.

    After 3 projects with EJB's I have stopped considering EJB's as a way to implement a pure object oriented design model.
    I use it now as an infrastructure that offers distribution, load balancing, transactions and a very primitive form of O/R mapping.
  3. General Entity Bean design problem[ Go to top ]

    Dirk offers sound advice. The use of Value Objects is not overdesigning.
  4. General Entity Bean design problem[ Go to top ]

    But with the introduction of Local Interfaces, (now that EJB2.0 is finally "final") is there any more need for Value Objects within the app server - for bean to bean communication that is?

    I do see the need for Value Objects for calls between a client and the Session Facade.