We're using an adapted version of FuseBuilder to generate our data components. Fusebuilder (as downloaded) generates useful qry_ fusefiles from a SQL Server DB. We adapted it to generate data components based on a PostgreSQL DB. I think Barry (who did all the work on this) plans to put something up on redev.org about this in the next few days.
The reason for having save and validate as separate functions is related to our procedural (vs event driven) presentation layer, I think. If you have validate() implicitly invoked by store() then presumably if validation fails, then validate(), and store() too, must throw exceptions and these must be caught by the caller, the presentation layer. I guess I've got a procedural mindset, as I've said before, it seems cleaner to me to say "Am I going to take the store fork, or the show error fork" rather than "I'll take the store fork ... whoops, (exception occurred) turns out I'm in the wrong place". As you say, an interesting discussion. It's certainly highlighted aspects of my thinking that I hadn't been aware of before. I've got a background in procedural languages, and I'm sold on OO, so I guess my outlook is procedural-OO, whereas yours seems to be event-driven- OO. I find it interesting that some people regard event-driven programming as something you must do when you go for an OO language, whereas to me event-driven programming is a separate concept. I'm now looking for an opportunity to apply event-driven principles (Mach-II probably) to an application :-) Does procedural-OO make sense as a concept ? I've got a suspicion I may get a lot of flak for this :-) Cheers, Andy. --- "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > How do you go about generating your data layer objects from your database? > Some sort of automated process? I'd be very interested to see how that > works. The lack of a good IDE for CFCs makes for a lot of legwork that I'd > love to avoid. I assume that your data layer is doing type checking and > such, but all the business validation is in the business layer components? > > I don't like to store data in the database with implicit extra information > (negative superusers), but I've somehow had several projects adopted in my > name. I've run into a few situations where I can't touch the persistance > layer, only the code, so I've had to make do as I can. My CFCs have methods > like isSuperUser(), so the code doesn't know anything about the bad DB > schema, but the encapsulation has to happen somewhere. I've taken a lot of > poorly written systems and rebuilt their insides over time to work > "properly", so I have a bias towards ensuring I have flexibility that I can > later remove when I can get to a point to fix whatever baddness I'm > encapsulating. > > To return full circuit, I'm still missing why you force the client code to > call 'validate' before 'store'. 'store' definitely has to ensure it has > valid data first, and it can do that by calling 'validate' itself, but I > still only see drawbacks with forcing the user to call 'validate' first, > regardless if the data is already valid. > > A very interesting discussion, I must say. Totally makes it worth wading > through all the other messages on here and CF-Talk every day. > > cheers, > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of cf_nut > > Sent: Tuesday, October 07, 2003 2:57 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] Data validation > > > > > > Hi Barney, > > > > I think I'm starting to see where our differences arise :-) > > > > CFTRY vs CFIF: > > -------------- > > > > I hadn't thought of the differences in approaches being procedural > > vs event-driven, but that ties in well with the fact that the caller > > of the objects, in our case, is a presentation layer written in > > FuseBox3. When I do something in Mach II I'll have to see how my > > view of things changes. > > > > 'store' forces 'validate': > > -------------------------- > > > > Our differences seem to come from the fact that you want to store in > > your database data which does not conform to the business rules but > > which you regard as valid in some other sense. I haven't hit that > > eventuality yet, and I can't forsee doing it. (I don't think I'd > > handle super-users the way you do for instance). In the event that I > > needed to however, I could do it by other means, and that relates to > > your point about where (in which object) the store method exists. > > > > The object I was originally talking about, with validate and store > > methods, exists in our business layer. The method that actually > > updates the database would be an update or insert method in a > > parallel object in our data layer. The business layer store method > > would call the data layer insert or update methods as required. Our > > data layer components are actually generated from the database > > itself. So we have the backend abstracted as you do, it's just > > separated in a different way. > > > > So going back to storing valid data (that doesn't conform to > > business rules) I might (perhaps, haven't fully thought this > > through) go about create specific methods for those eventualities in > > the business layer, that call the data layer methods in a different > > fashion, and perhaps bypass validation. So my user object (business > > layer) might have both a store() method and a storeSuperUser() > > method for the special case. > > > > Your code example is pretty close to what we do, by the way. Our > > return value from validation is a structure, but your use of a > > string keeps the example short. > > > > Cheers, Andy > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word '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 word '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]
