At 13:33 21.02.2001 , you wrote:
>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.
I disagree. the validation he's talking about will be fine in an entity
bean. Don't see any reason for putting that in a session bean (see earlier
posting).
>The consequence of this is that entity beans have become
>so thin, that JDO is becoming a popular (light-weight)
Have you read the JDO spec? I personally find parts of it rather ugly,
especially the query part. If some issues are clarified in the CMP2.0 spec
I would prefer take that in an EJB environment. Apart from that the JDO
spec seems to be moving on rather slowly, despite the recent draft but of
course YMMV.
regards,
robert
>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]>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
> >
> >
(-) Robert Krüger
(-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
(-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
