Architecture Question - Domain Object Validation

Good day,

I am trying to figure out how to uniformly handle domain objects which
self-validate. I have an interface named IDomainObject that exposes a
public method called Validate(). A lot of the implementation is
fairly straightforward. I do have a couple of scenarios that pose a
bit of a problem, and I was hoping to get some advice from someone who
might have run into a similar issue.

For the example, let us use the CreditCard object, which is part of a
composite class that represents a user signing up on a site and making
a payment. To make it simple, this object has getters and setters for
card number, card type, cardholder name, and expiration date. Some of
the validation rules which could throw an exception would be invalid
card number (InvalidCardNumberException), invalid card type
(InvalidCardTypeException), and expired expiration date
(ExpiredCardExpirationException). (The validation rules are separate
classes implementing an IValidationRule interface outside of the
Domain Object itself.)

The problem is that the business requirements for this object requires
that we have a means to display all of the problems in the UI layer
that exist at the same time, so it is possible to have any combination
of the example exceptions at the point of validation. There is no
problem in testing for all of them, but what would be the cleanest way
to store these? Should there be an Exceptions collection on the
Domain Object or is there some other way to implement this without
creating a one-off hack for the scenario where multiple problems could
exist at once?

I have also thought about having a single "super-exception" for all
things credit card related (and probably still will for type checking
purposes tied to the Domain Object). I just don't want to do
something dodgy like having the exception message list out all of the
problems, since there is a chance that the message in the UI could
change - causing a ripple effect that would force the assembly to be
modified, as well.

Any recommendations would be greatly appreciated! If there is a
better MS group for this, I would be more than happy to post this
there, as well.

Thanks in advance,

Joseph

Re: Architecture Question - Domain Object Validation

For anyone that might be interested, what follows is what I came up
with for my implementation. It does appear to work well and handle
the cases that I was worried about.

First, there is a rule collection on each domain object, as derived
from the base class that I defined for my domain objects. The base
class exposes a Validate() method that is overloaded to either take no
parameters, or a single parameter of a custom Rule type. When the
domain objects are populated, in my case with a domain object factory
hybrid, I can attach a predesignated set of rules. Calling Validate()
will run through all of the rules in the order that they were
attached, raising a singular exception for the first failing rule. If
I am looking for more granularity, I can pass rules in an adhoc manner
through the overload and specifically attempt to catch each exception
for a given rule. While this is a little more cumbersome than I was
looking for in a solution, the usage of adhoc validation will most
likely be very limited.

I can extend this approach to come up with some sort of validation
classes that will aggregate the series of individual results to
improve readability, but that would probably be overkill for a 5% (at
best) scenario.

Thanks again,

Joseph

On Mar 31, 11:46=A0am, Joseph Ferris wrote:
> Good day,
>
> I am trying to figure out how to uniformly handle domain objects which
> self-validate. =A0I have an interface named IDomainObject that exposes a
> public method called Validate(). =A0A lot of the implementation is
> fairly straightforward. =A0I do have a couple of scenarios that pose a
> bit of a problem, and I was hoping to get some advice from someone who
> might have run into a similar issue.
>
> For the example, let us use the CreditCard object, which is part of a
> composite class that represents a user signing up on a site and making
> a payment. =A0To make it simple, this object has getters and setters for
> card number, card type, cardholder name, and expiration date. =A0Some of
> the validation rules which could throw an exception would be invalid
> card number (InvalidCardNumberException), invalid card type
> (InvalidCardTypeException), and expired expiration date
> (ExpiredCardExpirationException). =A0(The validation rules are separate
> classes implementing an IValidationRule interface outside of the
> Domain Object itself.)
>
> The problem is that the business requirements for this object requires
> that we have a means to display all of the problems in the UI layer
> that exist at the same time, so it is possible to have any combination
> of the example exceptions at the point of validation. =A0There is no
> problem in testing for all of them, but what would be the cleanest way
> to store these? =A0Should there be an Exceptions collection on the
> Domain Object or is there some other way to implement this without
> creating a one-off hack for the scenario where multiple problems could
> exist at once?
>
> I have also thought about having a single "super-exception" for all
> things credit card related (and probably still will for type checking
> purposes tied to the Domain Object). =A0I just don't want to do
> something dodgy like having the exception message list out all of the
> problems, since there is a chance that the message in the UI could
> change - causing a ripple effect that would force the assembly to be
> modified, as well.
>
> Any recommendations would be greatly appreciated! =A0If there is a
> better MS group for this, I would be more than happy to post this
> there, as well.
>
> Thanks in advance,
>
> Joseph