This makes we want to ask a question that has nagged me for
a while. Where do you put data constraints? In the database?
or in the entity bean?
For example, let's say we have a field called "absoluteTemp"
in Kelvin. We all know this value can never be negative (in
my universe anyway). This isn't a business rule, it a law
of nature. Do you implement it as a database constraint which
will throw a SQLException if violated, or do you check for
in some facade-setter of the entity and throw some other
Exception if violated? What are the pros and cons of either?
-tim
> -----Original Message-----
> From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 21, 2001 5:25 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?
>
>
> 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
> >>
> >>
> >
> >
> >
>
