On 4/26/05, Andrew Scott <[EMAIL PROTECTED]> wrote: > 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.
Well, I'll contend that you do not understand OOP at all if you think Hotel can be extended by Floor or by Elevator. And if you don't get Business Objects, Data Access Objects etc then you don't get OOP either. Not a judgment, just a clarification of where you are on the path. As someone else quoted me: This stuff is hard. Have a read of the Mach II Development Guide since it talks about some basic OO stuff and then goes on to talk about how to design models and views and so on. You've already been given a load of links to very good material on Joe Rinehart's site (and if you don't believe Mach II can help you then look at Model-Glue - although I'd be very curious as to why you think Mach II cannot support what you're trying to do since your understanding of MVC in CF is such that you probably don't understand how Mach II works). > 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. Another option which no one has mentioned yet is to use Fusebox with a CFC model (or a Tartan CFC model). In that scenario, Fusebox is your controller, Tartan or raw CFCs are your model and plain ol' CFML files are your view. Tartan helps with structuring your model (the other frameworks do not). > 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. No, MVC really has nothing to do with separating data access out of your business object. Business object = employer.cfc Data access object = employerdao.cfc Both of those are part of the M - model. > I have read many articles on MVC so I understand that Then you would know that it has nothing to do with structuring database access... :) > problem I have found is that there is many frameworks, but no real > discussion on how to separate the logic, and data objects. Design patterns. Lots of articles on design patterns and those cover this sort of stuff. The J2EE Core Patterns book (available online). Martin Fowler's Patterns of Enterprise Application Architecture (or whatever it's called) covers various mechanisms for structuring data access. -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- 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]
