Hi Richard,
Thanks for the comprehensive reply. I do have some comments:
<richard>
Validation is usually not that complex so I'm not sure that this is a good
enough reason to avoid stored procedures. In cases where validation is
complex,
like validating XML, then a stored procedure is obviously not appropriate
anyway.
</richard>
If the validation is not complex would you agree then that there might be
reason for duplicating the validation in a java class to stop incurring the
round trip cost no matter how big or small. But note even the slightest
delay is noticeable to an user and if the validation is simple then the user
will quickly get iritated when after entering a few fields and pressing OK
it comes back with transaction rollback because.....bla..bla...bla.s SQL
CODE XXXXXX XXXXXXXX. All because he forgot to enter an age greater than 18.
The problem is users have become spoiled by the Visual Basic applications
which have included all the business logic including the validation in the
client process. We could probably view the stored procedure logic as 2nd
line defense for these guys and first line defense for others.
<richard>
It can be argued that lots of validation logic in the beans can pollute the
business logic making it more difficult to maintain.
</richard>
In some cases the validation is an important business rule that should be
attached to the bean. People usually view the addition of this to the bean
as pollution but thats probably because it has been added to the beans code
and not placed in a helper class i.e. policy, which can be dynamically
loaded by the bean and thus be replaced by a customized one
(interface/implementation); even in realtime with a hot deploy mechanism.
The pollution opinion comes from seeing the one bean class file grow over
time instead of the component becoming richer. Of course Richard it all
depends what we view as 'business logic' and 'validation' and what kind of
bean we are talking about i.e. session or entity.
<richard>
Good points. Of course this assumes that a great deal of latency occurs
during
database access which is not always the case.
<richard>
If we are talking about from the client to the database then yes.
<richard>
Very good points. If validation fails on the back end or with-in the bean,
the
transaction will be aborted and rollbacks may occur regardless of where its
validated.
<richard>
The issue I have is that instead of throwing back some JDBC SQL Exception I
would like to throw a XXXXValidationException which is more discriptive and
also can be handled more intelligently by the client application. As stated
previously I would like to throw it as early possible so as not to waste any
cpu cycles on the server or database box. I have some clients who are
building billing systems with Enterprise Javabeans where this is very
important especially when you have a billable tree structure.
regards
William Louth
Inprise
www.inprise.com/appserver
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
