I think this is a matter of taste more than anything. Mine is
developing in terms of EJB so I'll apply some first principles
to your question.
While I see how one could elide the BankAssociate entirely
I'd probably not do that myself. Rather I would presuppose
that all of the rules about how an Account should be manipulated
could not a priori be constrained to exist elegantly within
that class.
That being said I know nothing about this particular application
and would be willing to accept being accept that, in this case,
such separation would be overkill.
---Rick
Alex Smith <[EMAIL PROTECTED]> writes:
> Rick,
>
> Let's examine this stateless session bean. I believe this is
> what Mark Hapner is referring to in his email as "another tier"
> that sits between between the client (servlet) and the entity bean.
>
> public interface Account extends javax.ejb.EJBObject {
>
> public void setName(String name);
> public void setNumber(String number);
> public void setBalance(String balance);
> public void setAccountValue(AccountValue value);
> }
>
> public class AccountValue {
>
> public String name;
> public String number;
> public String balance;
> }
>
> public interface BankAssociate extends javax.ejb.EJBObject {
>
> // stateless session bean wrapping Account
>
> public void setupAccount(AccountValue value);
> public void modifyAccount(AccountValue value);
> }
>
> where setupAccount will blindly call all setXXX methods
> in Account's interface and modifyAccount will only call
> those setXXX methods where a corresponding property in
> AccountValue is not null. Both of these cases can be
> handled by putting the very same logic into the implementation of
> Account's setAccountValue method and therefore eliminating
> the need for BankAssociate altogether. If so, all setXXX methods can be made
> private and not show up in Account's interface.
>
> Is there a better solution that I am not considering?
>
> Alex Smith
> INSight LLC
>
>
> >From: Rick Kitts <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: Re: [EJB-INT] Demarcating transactions
> >Date: Fri, 30 Jun 2000 08:10:51 -0700
> >
> >(I'm brand new to this EJB stuff so apologies if I'm completely
> >off base here.)
> >
> >I don't understand the all or nothing sort of scheme implied
> >by the commentary. Is it not reasonable to create this flow?
> >
> >1 - Servlet gets data and bulks them up
> >2 - Servlet creates a (stateless) session bean
> > and passes in the bulk item. The session
> > bean starts the transaction (TX_REQUIRED)
> >3 - Sesssion bean creates the entity bean and
> > for each element in the bulk item calls the
> > appropriate setXXX() method.
> >
> >As for the scenario of updating the account
> >data wouldn't one simply create a new session
> >bean which performed that operation, perhaps
> >accepting only the relevant parameters and
> >calling the appropriate setXXX() methods? I'm
> >not sure I'd actually do that or make the session
> >bean smart enough to understand how to recognize
> >an incomplete bulk item and only call the appropriate
> >setXXX() methods.
> >
> >This, BTW, appears to me to be one motivator for
> >the notion that entity beans should "only" be accessed
> >via session beans.
>
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
--
------------------------------------------------------
Rick Kitts | The only thing worse than
Software Architect | generalizing from one example
DigitalThink, Inc. | is generalizing from no examples
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
