I frequently hear this mantra repeated, and while it is largely a good
idea, I have difficulty seeing why it should be adhered to dogmatically.
There is value in being able to define side-effects of setters and
getters or minimal bean-specific business logic. As a trivial example I
offer my Member entity which publishes getLastLoginDate(),
getLoginCount(), and a loggedIn() method which updates the previous two
fields. Creating a session bean for this purpose is just a waste of
effort and processing time.
An example of a simple (and valuable) side-effect is a print statement
to trace bean access while debugging.
As someone already mentioned in response to poster's original question:
You can do what you described safely because clients only see the remote
interface view of the bean, not the implementation object view. If you
chose to call the persistence field "internalBalance" and avoided
putting the setter/getter in the remote interface, you could then be
sure that everyone will call the get/setBalance method you implement.
But realize that sophisticated business logic does belong in session
beans. My main guideline is "does this affect more than the single
entity?" If so, then definitely it should be a session bean.
Otherwise, the answer is still maybe :-)
And in any case, the client view is of session beans only. For
instance, the Member.loggedIn() method only gets called from the
ejbCreate of my MemberSession stateful SB facade.
Jeff
>-----Original Message-----
>From: Brian Wing Shun Chan [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 22, 2001 12:30 PM
>To: Orion-Interest
>Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
>Subject: Re: No influence on CMP 2.0 getter setter methods - a feature
>or abug?
>
>
>You don't want to put logic in Entity beans. Entity beans should only
>serve as models for the database.
>
>Put the logic in the Session beans that will call setBalance
>and any other
>methods you have. You can make all those methods one atomic
>transaction by
>declaring it in the descriptor as well.
>
>- Brian Chan
>
>On Wed, 21 Feb 2001, Randahl Fink Isaksen wrote:
>
>> I have been reading the CMP 2.0 specification and I think it
>is simply
>> great! Still, I am a bit surprised that the bean developer
>has no control
>> over what happens when a field is set. Imagine an
>AccountBean, for instance:
>>
>> public abstract class AccountBean extends EntityBean {
>> //implemented by the persistence manager
>> public abstract Float getBalance();
>> //implemented by the persistence manager
>> public abstract void setBalance(Float balance);
>> }
>>
>> What if I wanted to do something useful when the balance was
>set? Say, I
>> wanted to add the account to a list of surveilled accounts
>if a negative
>> balance was set... it seems I cannot do that because the container
>> implements the setBalance() method for me. And I cannot just
>declare a
>> setBalance() method myself because I need the container's
>implementation or
>> I will not be able to store the balance. Hmmmm... it seems
>this is going to
>> leave me with something like
>>
>> public abstract class AccountBean extends EntityBean {
>> public abstract Float getBalance();
>> public abstract void setBalance(Float balance);
>>
>> public void
>setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance)
>> {
>> //check if balance is negative and take action
>> ...
>> setBalance(balance);
>> }
>> }
>>
>> Now I have _no_ guarantee that nobody will accidently call
>the original
>> setBalance() method, thereby circumventing my little
>security system, which
>> was supposed to check for a negative balance. But, hey, I
>thought, then I
>> will just declare the original setBalance() as protected -
>unfortunately
>> that is not allowed by the specification.
>>
>> I would r e a l l y like to hear from anybody who knows a
>solution to this.
>> Any comments would be most welcomed.
>>
>> Randahl
>>
>>
>
>
>
