1) Request Processor (a special layer which welcomes the request and
processes it (event-handler(s), its filters and listeners; unfortunately
Mach-II breaks the request processor into very scattered units))
a) welcomes the request, user, input data
b) does input validation
c) gets and puts data from BOs, DTOs
d) catches the application exceptions throwed by application objects
and services.
e) if a service is able to try-catch capability for its own
operations; request processor may not do extra validation for those
operations: for example, if DAO already throws an application exception for
unique username, the request processor may not validate the username
uniqueness, it may trust the DAO. But if DAO provides extra methods to
validate the username uniqueness, the request processor may use it to
validate the user name. This depends on the application-logic.
2) Application Objects And Services:
a) get and set data from db, file system, etc.
b) don't validate the data got from the Request Processor, trust it.
c) can do validations and throw exceptions for some operations like
checking file existence.
d) catch and parse the exceptions and make them understandable by
other application layers.
I've preferred this approach because it is enough, simple and increases the
productivity. I couldn't understand the horrible thing? I'm not sure whether
I understand your suggestion properly. Could you describe it more?
Murat.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert
> Sent: Wednesday, November 03, 2004 7:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Validation
>
> > IMHO, a strong input validation covers bussiness validation
> already, and
> > database provides extra validation for data-integrity. I
> think they are
> > enough, aren't they?
>
> Input validation can't cover business validation, unless your
> definition of input validation includes the definition of business
> validation, and mine doesn't. The unique username question is a
> perfect example. If you think that
>
> 1) doing a database call in input validation; or
> 2) letting the DB throw a unique key error and decyphering it
>
> is a good way to go, we have a fundemental disagreement. I personally
> think that both of those options are horrible. The first forces your
> UI controller to understand business rules, and the latter is just
> nasty to deal with, because chances are good that you'll have to do
> some text parsing to figure out which column is the problem (unless
> you 'know' which column, because there is only one unique key affected
> by the query, of course).
>
> In general, database constraints are not something to rely 100% on, as
> they're a persistance layer implementation of business rules, and
> consequently hard to use. I'd never do it by choice, but any
> application I build will happily run on a DB without any indexes or
> constraints (including foreign keys). I prefer leaving them in there
> so that i can more easily detect bugs in my code, to provide one last
> level of checking, and to deal with any DB interactions that don't
> come through the CF app.
>
> That's just my opinion, of course.
>
> cheers,
> barneyb
>
> On Wed, 3 Nov 2004 14:54:02 +0200, Murat Demirci
> <[EMAIL PROTECTED]> wrote:
> >
> > > One thing to keep in mind is that you need to make sure you're
> > > enforcing BUSINESS validation in your BO, not input
> validation, which
> > > should be enforced long before any data gets to your
> business layer.
> > >
> > > cheers,
> > > barneyb
> >
> > The key point: what is the validation and its types? Does Business
> > Validation is really required after Input Validation?
> >
> > IMHO, a strong input validation covers bussiness validation
> already, and
> > database provides extra validation for data-integrity. I
> think they are
> > enough, aren't they?
> >
> >
> --
> Barney Boisvert
> [EMAIL PROTECTED]
> 360.319.6145
> http://www.barneyb.com/blog/
>
> I currently have 0 GMail invites for the taking
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[EMAIL PROTECTED]
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
