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.
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.
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.
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.
Ah well the joys of having to work in the past, present and future at the
same time.
William Louth
Inprise
www.inprise.com/appserver
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
Sent: Wednesday, August 30, 2000 6:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Where should validation take place?
I wouldn't give up on validating the data in stored procedure so quickly.
While
it's true that validating the data in stored procedures does not allow you
to
easily migrate to other databases, this may not be a concern. For many
organizations the brand of database will never change ... its simply too
costly
to change to another vendor. This is especially true of large organizations
with
mission critical industrial strength databases like DB2 or Oracle.
If fact, I'll argue that for many organizations the brand of database will
long
out live the applications that use them, especially modern systems like EJB
will
tend to be re-engineered over time while the brand database never changes.
If
your database is shared by other systems and is unlikely to change then feel
free to place some validation logic in the database, so that its reusable
across
systems. BUT, don't over do it. Common sense is needed. If a particular
validation is only specific to your application or you can easily test it
before
submitting the data to the database it's worth doing in the EJB system. In
O'Rielly's EJB book there is a section about placing validation logic in
dependent objects so that some data (address, credit card info, et.) can be
validated when its created on the client.
If, however, you are creating a system that will be implemented over
different,
possibly arbitrary, database then avoid placing validation logic in the
database for the reasons that William rightly pointed out.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition
Published by O'Reilly & Associates
http://www.EjbNow.com
Adena Galinsky wrote:
> William,
> Yes, we've considered that case. We've also considered the case where
> another application would be accessing or updating our data through a
route
> other than our ejb's. (This, for business reasons, is likely to be the
> case) If this scenario comes to pass, if we have no data validation in
the
> database, then it appears that we are not sufficiently prepared to handle
> bad data when it arrives in the db.
>
> It looks like the best thing to do is validate data in our ejb code now,
and
> if at some point some other application needs to use our db directly, then
> we'll add the validation code there...
>
> -Adena
>
> -----Original Message-----
> From: William Louth [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 29, 2000 10:08 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [EJB-INT] Where should validation take place?
>
> Adena,
>
> Have you consider the case where you need to migrate to another database
> vendors solution. Those stored procedures will not be portable never mind
> the issues with trying to get a proper development environment for their
> development and testing. You might also consider the round trip cost.
>
> William Louth
> Inprise
>
> www.inprise.com
> www.inprise.com/appserver/
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Adena Galinsky
> Sent: Monday, August 28, 2000 4:42 PM
> To: [EMAIL PROTECTED]
> Subject: Where should validation take place?
>
> I've heard that data validation should take place in the entity bean (to
> centralize the logic), or a dependent object (to centralize the logic
while
> also allowing it to execute on the client).
> Should there also be data validation in the stored procedures in the
> database? On the one hand it seems redundant, but on the other hand it
> seems the only safe way to go.
>
> -Adena
===========================================================================
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".
===========================================================================
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".
