Where to put validation logic...

Question

Hi,
We have a lot of validation logic in our database. Next to the normal foreign key, check, unique constraints, we use triggers for validation (which throw errors with custom error codes when needed).
On top of the database we are building a fairly large JClient based application using the BC4J framework. BC4J offers the possibility to use validation beans for validating the entity row. We are wondering if we should use this. If we implement the validation logic for each entity we are actually duplicating the validation logic that's already available in the database. And some database constraints are easily implemented using the standard validation beans (like not null and unique checks), but more complex validation rules can sometimes only be done in the database (so we need to use the database for validation using a method validation bean).
Like I said this means a lot of duplicating validation logic. Which first of all is an inefficient thing to do. Second validation logic can change over time, which means we need to change the logic on two places. It's easy to forget to change the logic on one place.
We found a way to somewhat use the database validation logic for validating entity rows. We just simple insert a row in the database and post the changes. If the new row contains an error an exception is thrown. This JBO exception contains a reference to the SQL exception. Which can be used to retrieve the database error code. Unfortunately we have not found a good way (yet) to find out where the error occured (in which trigger for example). Error codes don't have to be unique so it's important to know in which context they occured. Another problem with this method is we can't do an early validate on a limitted set of row data. E.g. we sometimes use wizards in our application for adding new rows. We really want to check the data after each step in the wizard (step by step). This is ofcourse impossible with the database logic. This means we again need to create the same validation logic again. I don't think it's even possible to use the row.validate() method for this (and ofcourse implement the validation logic in the entity too), because this method validates the complete row.
In short, where is the best way to put validation logic? And (how) can this be done without duplicating (to much) logic?
Regards,
Peter
P.S.
Does anyone know how to retrieve the context of an SQL exception?

Answer 1

Do you users have access to the data/tables outside
of using your application? (as in using sqlplus?)Not at the moment.
Ideally the database should just be going
constraint--data integrity type of checks. The
business rules would be in the business layer not
persitance layer..So in this case, they would be in
the bc4j entity objects.. Well most of them are simple integrity constraints, but sometimes we have to check things using triggers which are way more complicated and need extensive database access. It's more logical to do that in the database. If the trigger runs into a problem it raises an application error. We are hoping we can use this error somehow in our application.
That assumes that the only way a user can modify that
data is through your application only.Well it is, and if another application is written for it the BC4J entities etc. will probably be re-used, but like I said there are other reasons for not having all the business-rules in the BC4J layer.
by the way, are you migrating an existing application
that already has all the business rules in the
database?No, it's a brand new application, but we started out with defining a lot of business rules in the database because that seems a more logical place to put them (to us). I understand that some business-rules can better be implemented in the BC4J entities, but it's not that easy for every business rule we have.
Regards,
Peter