> > But my beans already contain the validation! Besides, performing the
> validation in the ActionForm is effectively tying business logic (data
> validation) to the web framework dontya think?
>
> Well, I put data type and required field validation only in the bean.
> Validation that is more advanced than that, or based on business rules
> should be in your app server (if you have one), or in the
> action object.
>
While the response might be OK in a specific solution,
I think it is, in general, the wrong partitioning
of the validation issue. The questioner was more on
the correct track.
To understand the more general case, consider the
case where a company has a database(s) and is
developing multiple applications, some may even
be developed by 3rd parties.
How do they look at the data validation issue?
Any DB administrator will tell you HE/SHE is
responsible for the DB integrity, not the
(irresponsible :-) app developers:
- The data integrity issues need to be defined
by those who really understand and are
responsible for them. This includes business
data rules.
- You don't want to replicate the validation in
multiple applications.
- You don't want to have to change multiple
applications and the database simultaneously
if there are changes.
- etc., etc., etc.
Note that this doesn't mean ALL validation is
associated with the database, just that which
relates to the data model and the business integrity of
the data base. If one app requires certain data,
another app different data, and the database doesn't
care, then it is the application responsibility.
To address this we defined a set of objects which
front the database. They worry not only about
validation, but also things specific to the database
(e.g. query language), connection pooling, etc.
To work well with web applications these objects
need to have a validation interface that lets you
provide the total set of new (string?) data and allows
the object to return field-specific and object-general
error information.
This is also a good place to place the common
"business data rules" (not "application rules") so
that all applications use one common set, maintenance
is consistent, etc.
In VERY simple cases you could merge this with Action
classes, but generally there are significant differences,
no 1-1 relationship, etc.
Frank Lawlor
Athens Group, Inc.
(512) 345-0600 x151
Athens Group, an employee-owned consulting firm integrating technology
strategy and software solutions.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
