As I see it (certainly up for debate), there are two different
situations regarding BOs and validation (matching your two
alternatives).

1) A BO is never invalid, so on every setter, you need to ensure that
the BO's internal state remains valid.  If the invocation would result
in an invalid state, then an exception should be raised.

2) A BO can be valid, but the BO cannot be commited to the database
until it passes validation.  Passing validation is enforced by "the
system", where the system is the object in charge of persistance
operations.

The latter is really using your single BO as both a BO and DTO (data
transfer object), while the former is better in terms of tight
cohesion.  I don't know that one is really wrong,   I've done things
both ways, but I'd go with the first option all other things being
equal.

One thing to keep in mind is that you need to make sure you're
enforcing BUSINESS validation in your BO, not input validation, which
should be enforced long before any data gets to your business layer.

cheers,
barneyb

On Mon, 1 Nov 2004 20:14:10 -0600, Dawson, Michael <[EMAIL PROTECTED]> wrote:
> I ask myself this same question every day.  How much work should the
> setter do?  Should it know everything it needs to know to prevent an
> error or invalid data from occuring?
> 
> Along these lines, which would be a better solution:
> 1. Have the setter throw an error on invalid data assignment.
> 2. Have the setter set any value that passes the argument test, then,
> call a "validate" method to determine if the data is valid for its use
> in the object.
> 
> M!ke
> 
-- 
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/blog/

I currently have 0 GMail invites for the taking
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to