RE: Application design

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Booth Martin
>
> But Joe... you answered a question I didn't ask.  I said "adding
> an address"
>
> Where I was going with this example was i wanted to see which layer
> determined that "Qu" was an invalid entry, and how it would respond.

Validation and error reporting depends on your application design.  I can
pick three answers off the top of my head:

1. Validation at post (data deployment layer)

Errors are designed into the database, using either values clauses or
referential integrity.  You attempt to post the address to the database
using the "PutAddress" method.  This method can return multiple errors, one
of which is "invalid state/province".  This error is percolated up through
the layers.

2. Validation in business logic (business attribute layer)

Values clauses can be hardcoded into the programs here, or else you can use
a database relationship.  In this case, though, the database relationship is
accessed through the data deployment layer.  It's a level of abstraction:

        CheckState(newState)

3. Validation in presentation layer

Here, the presentation layer makes a request for a list of valid states.
This request is made to the business logic layer, which in turn queries the
data deployment layer:

        GetStates()
        GetStates(countrycode)

In this case, the presentation must be smart enough to validate against the
list.  In my world, I'd have a pointer to a StateList object, which could
both be used to format an input field (for presentation) and validate that
field.


Which is correct?  That's going to depend on your database deployment
mechanism.  For those heavy on referential integrity and triggers, the first
method is probably required.  The second method uses more traditional
database techniques, and is probably better suited for legacy databases.
You can combine the two in certain cases, using RI techniques for simple
attribute/relationship editing and business logic for more complex edits.

In either case, though, you may need to employ the presentation layer
validation, for performance if nothing else.  The ability to perform quick
validations, either clietn-side or immediately (that is, without having to
go to a validation server) server-side may be important in certain
architectures.

The point is that the four-tier architecture doesn't preclude any of these
capabilities.  All it does is stop the client-side programs from directly
accessing the database.  It takes a little more work, but in the end it's
far more flexible.

Joe