re 1: overloaded constructors are not always convenient. a design that
accommodates all needs seems to be highly desired. avoiding
mutator/accessor isn't necessary if in-process communication can be
achieved.
re 2: validating data intra-object is necessary but rarely satisfies all
requirements. inter-object validation is much more necessary and is not
well handled on the client.
accommodating #1 is simple; use a Command/CommandList structure.
commands are added to an execution list in any manner you've implemented
the Command interface. since Command is an interface, you can mix
Command implementations in the same CommandList (which also implements
Command). after all commands are added to the execution list, the
CommandList is executed (it controls the transaction - and provides the
option of executing all Commands within the list even if one fails,
aiding debugging efforts). results of the execution (including
Exceptions) are stored in the Command objects, packaged however you want
(we use custom JDK2 collections). Command/CommandList can be agents
allowing you to load up the command list in point A and activate it to
visit the locations requested in each Command for in-process execution.
after execution, the Command/CommandList returns home for in-process use
of results. most of our commands are executed using reflection which
allows maximum flexibility everywhere. we're doing almost all of this
today and it's way cool and way^2 fast!
for a descriptoin of Command/CommandList, review Buschmann and Gamma
accommodating #2... sorry, i'll disclose only one secret per day ;)
> -----Original Message-----
> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, February 22, 1999 8:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Pass-by-Value (was:RE: Question regarding Session
> and Entity Bean s)
>
> 1.) The Address object has a constructor which takes the attributes
> needed
> to describe the address.
>
> 2.) Data validation is definitely tricky. I have seen the ideas for
> using a
> client created object that validates the data prior to passing to the
> component. This idea is not without merrit. In this case the object
> would
> be mutable, but its role would be restricted to passing only data
> relevant
> to the change. It would not have a complex object graph and would
> remain
> fine-grained (limited to input validation).
>
> Input validation would be limited to ensuring, for example, that to
> and from
> dates are consistent or that String fields don't contain strange
> charters.
> Personally, I would rather see this type of validation in the GUI but
> for
> reuse I can grudgingly see it defined in PBV object.
>
> The validation PBV object should, other then validation of logic, be
> little
> more then a convenient packaging strategy for passing several values
> at
> once. This strategy does have its own problems. You end up with many
> of
> these fine-grained PBVs whose only purpose is validation and to pass a
> collection of data to a workflow object for further process. I much
> prefer
> the "icky" long method definitions over this type of validation object
> discussed here.
>
> Again the stress is to avoid set and gets - that's a business object
> design.
> We are doing Server-side Business Component Design, which is very
> different.
> Avoid sets and gets and focus your attention of the workflow - what
> are you
> attempting to accomplish.
>
>
===========================================================================
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".
