Hi William:
You have made many excellent points, which are well thought out and clearly
stated.
I've tried to respond to each (see below) but the bottom line is this: Use
storage procedures as appropriate and don't become married to any one solution.
Be flexible and explore all the options and use solutions in combinations as
appropriate. Stored procedures are an appropriate solution provided your
database is accessed by many different systems (not just EJB) and the validation
logic is shared accross systems. Its just one solution of many.
For those that are interested I published an article some time back on
validation in the now defunct "Distribute Computing" magazine. You can download
a draft from my web site (http://www.ejbnow.com/Validation.pdf). It not
specific to EJB and doesn't consider stored procedures but it may still prove
useful to some folks.
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition
Published by O'Reilly & Associates
http://www.EjbNow.com
William Louth wrote:
> Hi Richard,
>
> I am interested in how your feel about spreading business entity logic over
> multiple design layers i.e. ejb and database in the case ignoring process
> and client logic. I do recognise that there is no straight answer and there
> is no 'one rule thats fits all'. But I do feel somewhat uncomfortable with
> some aspects relating to having the logic in the database. The
> uncomfortableness comes from many different perspectives:
>
> 1. Ease of development - currently the development support for stored
> procedures is pretty weak. Where as in the Java arena we have JBuilder quite
> an impressive product that provides numerous productivity features even in
> the distributed environment.
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.
> 2. Business logic - There is no single source where the business rules
> associated with a domain object are implemented. This can lead to numerous
> problems including duplication and inconsistency both in the code and
> documentation. It also proves harder for someone new to a project to get up
> and running quickly since he or she will need to view many sources to
> understand one single concept.
I view validation logic as a form of business logic which tends to be simpler
and less dependent on the context of scenario. For example, validating the
proper form of an e-mail address is simple. Validation that is not dependent on
context (a domain object for example) can easily be expressed in other tiers of
the system like the presentation or back end. The validation article (see link
above) explains that there are different kinds of validation logic and where
they should reside depends on its complexity and purpose.
It can be argued that lots of validation logic in the beans can pollute the
business logic making it more difficult to maintain.
> 3. Performance - There is a cost associated with the roundtrip between the
> client and database. The bean developer has a few options to alleviate this:
> one is to dispense to the client a validation object (as described in your
> book) and another is to validate within its own methods instead of waiting
> for the database insert or update to fail which can be expensive since the
> db must locate the row in question and then try to do perform the change. I
> do think that the database can perform all validation checks before this
> lookup. Also we now have incurred a hit to our performance with the remote
> call to the database.
Good points. Of course this assumes that a great deal of latency occurs during
database access which is not always the case.
>
>
> 4. Exception Handling - Unfortunately the JDBC drivers do not all return the
> most informative exceptions and are not always consistent. So how does the
> client be a bean or some other form handle jdbc exceptions in an intelligent
> way. In fact the client cannot even determine what exception will likely be
> thrown by a method call since it is not declared. Also in most container
> implementations the synchronization of the entity state with the database is
> peform at the end of the transaction. Thus your session bean cannot even
> trap the error, the client will be left with tx rollback, never mind the
> fact that the session bean could have broken some business rule from the
> start but continued on with other expensive operations. You might also
> consider the fact that the user of such an application would feel annoyed
> with being allowed to peform something then to suffer some latency before
> the whole thing blows up in his face.
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.
===========================================================================
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".
