I completely understand where you're trying to go. However, keep in mind
Entity beans are not meant to hold business rules. They are an interface
to
your physical storage.
We have solved that problem using a facade pattern that basically works
by
shielding the developper from the actual method being called on the
server.
For example:
Create an Entity bean AccountBean
Create a stateless session bean AccountBusinessRules
Leave the setBalance in the Entity Bean and add a setBalance in the
BusinessRules bean.
Use a reference to the remote interface as the first parameter, like
this :
public class AccountBusinessBean implements SessionBean
...
public setBalance(AccountBean ref, float balance)
{
// put the business code here...
// you can also use
ref.setBalance(balance);
}
... other business methods, not necessarily tied to remotes
The facade has the following generated code (with checks, try catch
etc.):
public class Account extends BusinessObject
public setBalance(float balance)
{
getBusinessBean().setBalance(getRemote(), balance);
}
... the other business methods calls
The client application instantiates the facade object
Account acct = new Account(new Integer(accountNumber)); // for
an existing entity
acct.setBalance(newBalance);
The client application developper does not know (or need to know?) which
method gets called. It's the
job of the developper providing the Bean.
So the trick is generating the facade. We use a java doclet that
generates our facade objects by
combining AccountBean methods with AccountBusinessRules methods. We use
method tags in the Entity
and Business beans to "inform" the doclet about how to process the
methods in the facade.
This allows an easy switch from a "pure" data set (method only in the
Entity Bean) to a business
method being called (both in Entity and BusinessRules) without impacting
existing client applications
in any way.
As a bonus, with stateless session beans, you get pooling of business
methods, which makes more
efficient use of the server's ressources than having the code in
stateful beans or entity beans (BMP).
This works very well for us. If you have better suggestions, let's
discuss them!
Cheers,
Daniel
-----Message d'origine-----
De : Randahl Fink Isaksen [mailto:[EMAIL PROTECTED]]
Envoyé : 21 février, 2001 11:46
À : Orion-Interest
Cc : Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
Objet : 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
