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]


Reply via email to