Although this sounds like it is better thought out... it sure isn't KISS (Keep It Simple Sam) is it?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murat Demirci Sent: Thursday, September 22, 2005 3:48 AM To: [email protected] Subject: [CFCDev] DAO, BO, TO/Bean relationships (was: suggestions for DAO generators for CF) 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]
