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".
