Again, see if you can dig up Joe's tutorial(s) on the DAO pattern. From everything i've seen, i think he's encapsulated the best practice as it exists today.
I tried my best to avoid using DAO's when i first got into CFC's thinking i would save myself the "effort", but as i went on, i found i was just making more work for myself. Why? Simply because cohesive objects are so much easier to understand and maintain. Once you start mixing too much stuff up in an object, you carry that baggage around everywhere in your app. In the end, you wind up writing the same number of lines of code, more or less. But lumping them all together in large objects messes my head up when i'm attempting to place myself in overview mode. And that slows me down ... The thing i like about making my objects more cohesive is that the app becomes much more flexible conceptually for me. Intelligent solutions seem to occur to me more easily when my building blocks are smaller. It's weird. It really looks like i'm making more work for myself encapsulating everything in all these functions and objects. But my experience is that it speeds up my development considerably - especially when the going gets more complex. You probably know this from your experience with other languages, but i find it holds true within ColdFusion just as well. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andrew Scott Sent: Wednesday, April 27, 2005 4:48 AM To: [email protected] Subject: RE: [CFCDev] MVC - Concept and Reality within Coldfusion Well I used Hotel as an example because Hotels all have floors, so within that object could be offices, lounges, toilets and elevators, which can all apply to a hotel object. Anyway the point I am making is that as much as I understand OOP, I am still not getting the BO, DAO and coldfusion with cfc's. I am very confident with CFC's but I think I could be writing my code better than I am writing it. So I wanted to know how people are using MVC's within coldfusion and separating the business logic, and DAO logic. For example, should I be writing an employer cfc, and everything related to this is of course in this cfc. But when I wish to store/get data from a database how do you integrate this into your objects. And keep the code to a minimum, this is my main point of understanding more than MVC's themselves. I have read many articles on MVC so I understand that, but I am just trying to get to grips how you guys/gals have separated business logic and dao. The problem I have found is that there is many frameworks, but no real discussion on how to separate the logic, and data objects. Regards Andrew Scott Technical Consultant NuSphere Pty Ltd Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9686 0485 - Fax: 03 9699 7976 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Dempsey Sent: Wednesday, 27 April 2005 11:18 AM To: [email protected] Subject: Re: [CFCDev] MVC - Concept and Reality within Coldfusion On Apr 26, 2005, at 5:54 PM, Andrew Scott wrote: > So if I have a simple class called Hotel. Which can be extended by > Floor, as well as Elevator. This I understand and comprehend, but the > business logic of storing/retrieving the data (DAO) is getting me a > little confused. > I'm not sure this is proper OOP. Neither Floor nor Elevator are a Hotel. Perhaps a Hotel is composed of Floor objects... > So with that in mind, what and how do you guys lay out your business > logic, > dao etc. I have a complex Intranet system that could benefit from this > method, but can't use MACH-II as the framework will not be supported by > MACH-II, please don't get me to explain this I have tried to get it to > work > with MACH-II just that we are doing things that MACH-II will not cope > with. I bet there is people on this list that can help with that too! > So with breaking the logic, and views down to a smaller and manageable > package I would like to break down the code we currently have and start > creating a more package orientated approach. But would like to see how > others are approaching this as well. > I first created my namespace, edu.ucsb.graddiv. I then grouped related objects together in packages, then subpackages, and so on. For example, within the graddiv package is a student and an employee package. Within the student package are separate packages for prospective students and enrolled students. This goes on forever...if you've done it with Java, then it applies here, though you may want to have the list provide input on how you are extending objects and so on. Within each "leaf" package, like edu.ucsb.graddiv.student.prospectiveStudent, are a set of classes that break up functionality, including a Business Object, Data Access Object, Gateway, and occasionally Facades, Services, and Transfer Objects. Each of these patterns are described elsewhere in great detail. To read an object, I call read() on the DAO, which returns the BO. I update the BO, then call update(BO) to save the object. Gateways usually return recordsets, rather than objects. DAOs usually operate on one BO at a time. HTH, Chris -- *************************************** Chris Dempsey Director, Information Services UCSB Graduate Division Quidquid latine dictum sit, altum videtur. ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
