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]
