RE: No influence on CMP 2.0 getter setter methods - a feature or a bug?
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 fvrier, 2001 11:46
: Orion-Interest
Cc : Jens Peter Grosen; Simon Anker Christiansen; Kim Jrgensen
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. H... 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
Re: No influence on CMP 2.0 getter setter methods - a feature or a bug?
Hi Randahl,
Why don't you just leave the method setBalance(float b)
out of the remote interface and put
public void setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance)
in the remote interface. So no other objects can call setBalance but only
setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance).
Greetings Wim Veninga.
- Original Message -
From: "Randahl Fink Isaksen" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Cc: "Jens Peter Grosen" [EMAIL PROTECTED]; "Simon Anker Christiansen"
[EMAIL PROTECTED]; "Kim Jrgensen" [EMAIL PROTECTED]
Sent: Wednesday, February 21, 2001 5:46 PM
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. H... 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
RE: No influence on CMP 2.0 getter setter methods - a feature or a bug?
Yep, as I wrote in an earlier post, that was what I chose to do.
Randahl
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of wim veninga
Sent: 22. februar 2001 15:38
To: Orion-Interest
Subject: Re: No influence on CMP 2.0 getter setter methods - a feature
or a bug?
Hi Randahl,
Why don't you just leave the method setBalance(float b)
out of the remote interface and put
public void setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance)
in the remote interface. So no other objects can call setBalance but only
setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance).
Greetings Wim Veninga.
- Original Message -
From: "Randahl Fink Isaksen" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Cc: "Jens Peter Grosen" [EMAIL PROTECTED]; "Simon Anker Christiansen"
[EMAIL PROTECTED]; "Kim Jrgensen" [EMAIL PROTECTED]
Sent: Wednesday, February 21, 2001 5:46 PM
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. H... 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
RE: No influence on CMP 2.0 getter setter methods - a feature or a bug?
Title: RE: No influence on CMP 2.0 getter setter methods - a feature or a bug? 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). You're right. Personally, I wouldn't expose the get/set methods to a client due to the fact they may actually use them. This would slow the system down if they did it too much. Considering my users are ASP writers who took one JSP class and don't know RMI from a hole in the ground, I would suspect they would abuse the entity bean. I prefer to have a builder create a View pattern for me which I give to a session bean. The session bean would call the setters/getters within the container to minimize RMI load. My personal preference it to perform all validation in a session bean; to me these are business rules and don't belong in the entity. I suppose there are cases where some validation may not be considered a business rule and placed in the entity instead. 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. Haven't read Sun's JDO spec - I looked at another third party implementation. I didn't like it, but I wouldn't rule it out as being a good implementation. I'm talking out my ass here so I better stop. :) -tim
