>> Why do you prefer to use <cfargument>s in the DAOs for every columns?
personally I don't. We don't pass objects around in this framework but we do pass structures. I was just after the code generation and the ability to modify the generator. we call our DAO's "#packageName#.persist.cfc", while <cfargument of descrete values (esp type checking, field size execptions, null/not null, etc) is handled in our "#packageName#.service.cfc". for us, service and persist are (99% of the time) a 1:1 relationship. whatever generator I use will have to be mod'ed to make these 2 CFC's work "just so" it mightn't be the standard way of doing things as per people's discussions on this list but it's a framework that's over 12 months old now for us (so can't change) and besides, it's our "mousetrap" (ie: it works for us) I don't (generally ) disagree with anything you've said, Murat, but different strokes, etc... my 2c barry.b PS: so far, CFC creator looks promising, albiet with a few corrections that I'll post on Scotty's comments, to roll into V2. thanx for the link Callum b On 9/22/05, Murat Demirci <[EMAIL PROTECTED]> wrote: > Hi folks, > > I'm seeing some messages proving that there is a confusion about the > subject. > > Why do you prefer to use <cfargument>s in the DAOs for every columns? Why > don't you use TOs (or Beans) to transfer data to DAOs and BOs and get from > DAOs and BOs? > > The following architecture should help you: > > - Controllers talk with BOs using TOs. A controller can use more than one > BO. > - BOs talk with DAOs using TOs. > - Controllers shouldn't directly talk with DAOs > - BOs and DAOs might throw exceptions if the record cannot be found, cannot > be deleted, cannot be inserted/updated, etc. > - If necessary a BO can use more than one DAO > - If necessary a BO can use another BO > - TOs/Beans are typeless CFCs, every fields are string. > - Validation is done in controllers not in TOs/Beans. > - Validation should be done to be sure the TO/Bean contains valid data, but > the validation code can also check other Form fields which are not belong to > a TO/Bean. > - Validation is done before passing the TO/Bean to the BO, but after > populating the TO/Bean instance data using form fields. > - TOs/Beans can be usable by views. > - Validation does not throw exceptions, it generates an array of validation > errors which are used by the view. > - Generally validation does not need to be reusable. But some applications > might need complex and consistent validation logics which may lead to > duplicate code. To get rid of this use function libraries (utility CFCs). > - TOs/Beans are transfered by ref. If necessary, a DAO can change the data > in a TO/Bean which gained from cfargument. > - A NULL field in a DB is an empty string in a TO. cfqueryparam stores NULL > to the DB if the value is empty string. You might need to use null attribute > and yesNoFormat() function to bypass some exceptions of cfqueryparam if the > value is empty string. > - I prefer to use one DAO per one primary table. I don't use Gateway > components to decrease CFC count and increase maintenance ease. My DAOs > contain CRUD+Other methods related to the primary table and relationship > tables. > - I use DAOs because it will be easy to add additional DB support in the > future. I'll just change the DAOs. The idea behind the DAO is generally > this. Also some data access operations can be shared between BOs. > - File I/O, e-mail sending, cfhttp and other operations which does not need > system independency can be done in BOs. > - Security (isUserInRole, cflogin, etc) is done in controllers. > - Web Services are separate CFCs similar to the controllers. They use BOs to > reuse BOs. > - I store BOs, TOs/Beans, DAOs in the *Model* directory creating a new > directory for each module/subapplication. > > Murat. > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > 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' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
