Entity Bean Design Question


EJB design: Entity Bean Design Question

  1. Entity Bean Design Question (5 messages)

    Hi all, I have a question about Entity Bean's design.
    Should we design Entity Bean with the Object's logic
    inside or should we leave the logic to a Session Bean
    and use simply use the Entity Bean's gets and sets?

    For example, in a TraderEJB, which is the correct place
    to put a method like this?

    public void withdraw(int money) {

    if (this.getMoney() > money)
    ...throw Exception


    should we put it in the Entity Bean (so making it
    a coarse grained Entity Bean) or should we put the
    logic only in the Session Bean that acts as a facade?
    Hope I was clear.
    Thanks alot

    Threaded Messages (5)

  2. The accepted wisdom for this is to put business logic in session beans. So you should use the getters & setters, but it is accepable to put methods returning coarser grained value objects. For example, if you had a "person" entity bean, holding stiff like:

    Address Line 1
    Address Line 2
    Address Line 3
    Zip etc.

    Obviously if you wanted to get the person's address, you'd have to invoke 5 getters to retrieve it. A getAddress method returning a value object containing all the details could legitimately be placed inside the Entity.

    If tomorrow you decided that maybe Entity Beans weren't the way to persist your data, (maybe you decided, for some reason, to use JDBC instead) you'd have to move all the business logic back into the session beans anyway.
  3. Hi,

    You should not put that kind of logic in entity bean. I would suggest that
    Put your business logic in session beans or in controller components where you are calling your entity bean, for this particular instance you can use finder method like ejbFindMoney(money).... and return the value which is greater than the argument value.

    Dinesh Singh <dpsonline at hotmail dot com>
  4. I'm not quite sure about your example, because a "trader" seems more like a logical unit than an entity, and therefore would be implemented using a session bean. Of course in your application it may make sense, but it is hard for me to comment on it.
    If we had, say, an account entity, I would say the withdraw method should *definately* go in the account entity. There is a fine line between business logic and generic logic, but I think this case is perhaps the best example of that destinction. Withdrawing money from an account is an inherent operation performed on accounts: it is not a particular logic needed for a specific application. However, I'm not saying clients should access this method directly: factors like the size of an account over-draft, max withdrawal ammount, etc, is business logic, and shouldn't go in the entity itself. But the actual withdrawal operation should go in the entity. Entity beans are supposed to be OO views of business entities, not just a getter/setter, flat view of the data. IMO, methods instrinsic to the data should go with the data, as dictated by normal OO conventions.

  5. Hi thanks for your answer. I definively agree with you Gal. Also in my opinion Entity Bean shouldn't be just flat view of data. In this case the example is from Weblogic's sample Entity Bean Trader.
    Since the operation is tightly-coupled with the Account itself (checking for funds) in my opinion the Entity Bean should be able by itself to check if the operation can be done. Otherwise the Entity Bean is simply a wrapper to a DB....it wouldn't be worth to use them just for this....IMHO (of course!)
  6. Yes, what Gal says is perfectly correct if you are committed to using enitity beans. If not, just design a normal proper Java class that represents your business domain and use a SLSB for those transaction and security services. My honest opinion...just stop thinking of these EJBs. Think of your domain, the real business you've to model and model thm best using normal Java classes. Then see if you don't really get the services you really need from SLSBs. I'll be glad to hear if not.
    Thanks in advance,