Re: validation

In article <3ce3837a$0$8514$ed9e5944_at_reading.news.pipex.net>, you said (and I quote):

> I think its open to argument.

Not wrong...

>
> jonathan lewis posted a while back that the optimum strategy from a data
> security point of view was to be 'a real bastard to your users' i.e.
> validate at the data and just pass the error stack back.

That is the "defensive mode". Works. Lots of work, too.

>
> My view would be that you should validate seperately (but consistently!) at
> both layers. the app layer to ensure an effective user experience,the data
> layer to protect the data .

Yup, same here. I'd take it one step further. Data-specific validations (type, overflow of column capacity, null/not null and so on) I'd validate on the database.

Things like "a purchase order cannot be passed without approval if its value is > $1000" belong in the application. Note that validation of this requires a relationship between two attributes, possibly derived: the approval and the calculated total. If the application uses a table to get the "$1000", fine. But it is a business specific rule. It may be better located in the appserver code.

Often the separation line is hazy. Particularly when dealing with J2EE designers: for them everything has to be "decoupled" from anything that is not Java. And "coupled" with EJBeans. Bottom line: they simply shift the maintenance needs around and make them totally coupled to the app server. A total mistake, for which we have to thank Sun and their "illuminated" designers...

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam