On Tuesday, September 3, 2002, at 11:47 , Andrus Adamchik wrote:
> I was thinking more about the "dumb" form of EOValidation (string
> length and nulls), since I don't use NSValidation either.
But in this case, the "validation" will be performed over the board by
the access layer based on the model information, isn't it? That should
have nothing to do with the business object. Or am I missing something?
> But I am still for externalizing it, since setters are unaware of the
> context in which they are called.
Ummm? A validation does not have much more context. It simply check a
value and that is that.
> For instance a setter may be tied to the GUI, and user may perform a
> few corrections before the changes are committed.
> So it is really up to the setter caller to decide when the validation
> is needed.
I see. But in this case, there are really two separate issues:
validation in a setter for generic business logic and "context" specific
validation. The latter case is once again outside the realm of a
business object in my understanding and by extension a persistency
framework. And because it would be tied to some specific "usage" pattern
will most likely vary from case to case. So I guess it belong more in
something like EOInterface.
Cheers,
PA.
This archive was generated by hypermail 2.0.0 : Wed Sep 04 2002 - 08:25:50 EDT