I've been developing a similar application called cfcPowerTools. It's a code generator that will create CFCs from an existing database table or create the database table from the CFC. cfcPowerTools is a productivity tool that will generate the database table, build data entry form, and produce the CFC all at the same time. It also supports round trip editing so you can toggle between cfcPowerTools and manual modifications without losing code. Also, you can produce stand-alone CFCs that are completely independent of cfcPowerTools. cfcPowerTools will generate the SQL insert, update, select, and delete statements for each standalone CFC.
Please check out my site: http://www.cfcpowertools.com. You can download cfcPowerTools for a 30 day trial. There's also an informational movie about cfcPowerTools. Thanks Tom Schreck -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer - CMG, LLC Sent: Sunday, April 17, 2005 11:22 PM To: [email protected] Subject: Re: [CFCDev] object persistence Joseph... Haven't heard of CFSQLTool before... got a URL handy? I've released SQLSurveyor that generates DAOs, and has a live demo at http://w2ksrv1.neo.servequake.com/sqlsurveyor. The whole point of a DAO is to be able to wrap your SQL in a call to an object's method... in this case, read(id) will return the record from the table specified by the id... so if you were going after a person, 2 telephone numbers, and an address, you'd read the person, phone, and number records by calling read(personID), read(phoneNumber), etc., till you'd collected all the data you needed to. Granted, it's more complicated than that, but that's the 30,000 foot view. In a case like this, your Person object is only going to interact with other objects... which means that any changes that happen outside the Person object can be done without affecting the person object much, if at all, from a coding perspective. You can completely change the DB structure, and so long as your read/create/update/delete methods stay the same in terms of how the application interacts with them nothing inside the person object must change. And I would generally change the person object's instance data and then call the savePerson() or persist() method to write data... there's no point to a per-element DB write. Laterz, J PS - For more info on SQLSurveyor, see http://www.web-relevant.com/web-relevant/index.cfm?fuseaction=main.sqlsurvey or On 4/17/05, Joseph Flanigan <[EMAIL PROTECTED]> wrote: > Suppose Person Object is an abstract object that has persistent data in > multiple tables. For example, a contact of type person has zero or more > telephone numbers. Each telephone number is of a type telephone number. In > this case there are at a least 4 tables of data related to the person: > contact, contact type, telephone and telephone type. Person, because is > has complex relations with telephone cannot be a simple flat table. It is > disjointed and can only be joined by an external rule like a foreign > key. Consequently the application must provide data in sequences to > satisfy the join rules. > > In practice, I see abstract objects far more than simple objects. > > (Also, consider in ColdFusion, data type binding between ColdFusion and > database occur within the cfquery or cfstoredproc tags. > > In the code generated with CFSQLTool, each table or view has all the data > access functions, like CRUD, within the CFC. These are called wrappers. > Each wrapper function contains the SQL query and the data bindings. The > collection of wrappers make up the data access layer. The data access > layer's specific job is to conduct transactions with the database. > > Then, a convenient way to create an abstract object, like for person. is to > create a CFC service object called person that invokes each of the wrappers > as needed to implement the persistent data based on the business rule. The > CFC service generator is also in CFSQLTool because I needed a way to handle > disjoint abstract objects. > > Joseph > > At 01:32 PM 7/15/2004, you wrote: > >I'm curious what approach people use for persisting objects in the db. > >Let's say I have a Person object. Is it better to have that Person object > >contain all of the Business methods to work on the object as well as the > >methods to persist itself or is it better to set up a separate PersonDAO > >object that deals with all of the database interactions and keep all > >database interaction out of the Person object? > > > >Along those lines, I'm also curious how people actually do their > >updates. Do you first update all of the properties of an object and then > >call a Persisit() method or when a setter method is called do you have it > >update the object property and then update that property in the db? Seems > >like a lot of extra db traffic to do it the second way but it would cut > >down on some persistance logic. > > > >I'm still a little new at working with CFCs in a more OO way so any help > >would be greatly appreciated. > > > >Stephen > >---------------------------------------------------------- > >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] > > ----------------------------------------------------------------------- > http://www.switch-box.org/CFSQLTool/Download/ > > Switch_box MediaFirm, Inc. > www.Switch-box.org Loveland, CO USA > > ---------------------------------------------------------- > 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). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > -- Continuum Media Group LLC Burnsville, MN 55337 http://www.web-relevant.com http://www.web-relevant.com/blogs/cfobjective ---------------------------------------------------------- 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). 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). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
