proper n-tier validation

[Nick]

I was wondering other opinions on this topic... I am working on an n-tier
application which may be broken out to different servers at a later date.
How should I go about the validation? I would like to assume that the UI
later will handle a lot of this but I cannot be 100% set on this as another
developer may not expose all the validation rules if they make a new front
end. Right now my data access layer uses checks within the procedures as
well as constraints and foriegn keys. This however again doesn't make my
data 100% but helps a great deal. I was thinking about having a custom
exception in my BLL named ValidationException in which I can do all checks
there. This way when users screw up on entry I can catch this in the UI to
display a friendly error message instead of passing it to my exception
handler. I would still do client side validation as well to cut down on the
exceptions thrown. What are your thoughts on this method and is this quite
common in n-tier applications where there may be multiple developers working
on different UIs?

[Cowboy \(Gregory A. Beamer\)]

You certainly want to catch any simple errors you can easily catch on the UI
layer. For example a person puts "some words" in a date field. You can also
check basic email address, etc.

But, you also want to set up your system so it does not trust user input, so
your other layers should have checks as well. Any time you make a jump you
should consider some form of validation. If the system is distributed, but
closed (you have closed down access to the UI app you have only - not very
flexible, of course), you can be a bit more lax, but the saved cycles will
do less for scalability than other refinements. I would also not be fond of
this approach as you lock a variety of applications/services into a single
solution.

You should also make sure your database helps avoid obviously bad data.
Using proper data types, relations and constraints will cover most of your
needs here. Use triggers if there is something that is hypercritical that
requires logic.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"Nick" <nt********@online.nospam> wrote in message
news:71**********************************@microsof t.com...

I was wondering other opinions on this topic... I am working on an n-tier
application which may be broken out to different servers at a later date.
How should I go about the validation? I would like to assume that the UI
later will handle a lot of this but I cannot be 100% set on this as
another
developer may not expose all the validation rules if they make a new front
end. Right now my data access layer uses checks within the procedures as
well as constraints and foriegn keys. This however again doesn't make my
data 100% but helps a great deal. I was thinking about having a custom
exception in my BLL named ValidationException in which I can do all checks
there. This way when users screw up on entry I can catch this in the UI
to
display a friendly error message instead of passing it to my exception
handler. I would still do client side validation as well to cut down on
the
exceptions thrown. What are your thoughts on this method and is this
quite
common in n-tier applications where there may be multiple developers
working
on different UIs?