Having spent the last couple hours puzzling over it, I've decided that the
current approach of throwing exceptions of type validation just isn't good
enough.
On the grounds that input validation is 'expected' to fail because users enter garbage? :)
I'm currently leaning towards creating a validator service in the model that
allows you to pass in form data and returns a validation object/structure
that contains a key telling you if the validation succeeded as a whole and a
struct containing message and errorcode for each field that failed. The
presenter can then re-route back to the original form and the view layer can
decide whether to use the message from the model or use a custom one based
on the error code.
Sounds pretty good but don't forget i18n which would require your messages to be driven by locale...
The validation service can be called by the form action method in the
presenter layer before passing the data to the model to update the database.
Yes.
The question is whether or not the validation service should check whether
say a username already exists in the database, or only if the username
submitted has a valid length and characters.
I think that's a slippery slope. You don't really want to mix knowledge about the persistence mechanism (which in general might not be a database) with the input data validation routine. Besides, in a multi-threaded environment, checking the username exists prior to updating the database isn't guaranteed to produce unique entries in the database(**) so you still need a constraint on the database and you'll still have to deal with exceptions thrown for constraint violations.
** Consider two form submissions from different users for the same username. They press submit at the same time and both requests are being processed. Both check the username and find it is not present in the database. Both attempt to insert their respective record. Either (a) both will succeed if there is no DB constraint or (b) one will succeed and the other will violate the constraint and throw an exception.
There are also edge conditions where two users simultaneously sign up with
the same username and they both pass the validation check, but only one of
them gets added to the database. The other gets a data integrity error.
Ah, yes, we're on the same page :)
I think I can live with the edge conditions and I'm thinking that checking
for existing values in the database is probably the best way to go, but I'm
open to suggestions if anyone has a better idea.
I would be inclined to keep the lookup of the username out of the validation itself, but perform a lookup ahead of the validation and pass the result into the validation - or pass a user gateway object into the validation. That way the validator does not need to know about persistence.
Regards, Sean
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
