This is why the session-bean-wrapping-entity-bean pattern
is so popular. Do not implement business logic inside your
entity bean. Instead, have your client perform operations
to the data via a session bean. The session bean can test
for valid data, constraints, etc. before updating the entity.
The consequence of this is that entity beans have become
so thin, that JDO is becoming a popular (light-weight)
alternative to entity beans. Sun is examining JDO in a JSR,
but I don't suspect they'll kill off one of their children
in the process.
-tim
> -----Original Message-----
> From: Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 21, 2001 11:46 AM
> To: Orion-Interest
> Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim J�rgensen
> Subject: No influence on CMP 2.0 getter setter methods - a
> feature or a
> bug?
>
>
> 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
>
>
