I thought "holidayInn" was just an instance of a Hotel ?
----- Original Message ----- From: "Jared Rypka-Hauer - CMG, LLC" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 26, 2005 11:49 PM
Subject: Re: [CFCDev] MVC - Concept and Reality within Coldfusion
Hey Andrew...
Comments inline below...
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.
This is a better example of the Class Explosion pattern and composition. Inheritance says "holiday inn IS-A hotel" and "hotel HAS-A ballroom."
Just clarifying.
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.
If you have a business object called person.cfc, it might have a persist method, called... persist(userTO) where userTO is a Transfer Object (see recent posts to this list about transfer objects, beans, etc.) that simply contains a struct of user data... your persist method might look like this:
<cffunction name="persist">
<cfargument name="personTO" type="personTO">
<cfset var DAO =
createObject("component","personDAO").create(arguments["personTO"])>
</cffunction>So your person object is dependent on other objects for the services it needs in order to function... personTO carries data between layers of the app (or gets created by your business object and passed into your DAO). personDAO handles all the database transactions for a single DB row, and personGW (gateway) handles all the DB access for multiple rows (like getAllHappyPeople()).
In the case of using Tartan... your call would look more like this:
<cfset application.personService.savePersonData(personTO)>
Really, your whole model and persistence architecture can reside in Tartan, which can create Value Objects, use DAOs, modify or reformat data... it's it's a service-layer subsystem that provides the backend connections for a web app.
It's up to you to create the boundaries between your layers, and to decide that your framework talks to listeners (or controllers) talk to business objects talk to service objects talk to commands talk to DAOs talk to DB drivers... or however else you might arrange it, but that's the gist of n-tier development using CF. It's much more a mindset than a specification, and it does take some time to get used to.
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.
Actually it's not even that simple... employer.cfc might have a collection of composition objects called address.cfc, might have a collection of employee.cfc instances as well. It might have a persist or save method that uses a function-local instance of a DAO or service object that saves the data to the database... and it probably has a getTransferObject() method that returns specific instance data to be sent to the DAO and finally the database.
Really, your "model" should contain static relationships between your business objects... i.e. does an employer have an employee collection, or does it only get employees one at a time? Does the access to employee.cfc happen thru employer.cfc, or is an employee something you can create ouside a specific relationship with an employer? That's the sort of question your model should answer.
Your business logic goes in the framework... in CFC files to actually do the work and XML files to inform the framework of what CFCs are where for doing what. Configuring listeners or filters in MachII and/or controllers and broadcasts in ModelGlue, controller/model circuits in Fusebox... and the appropriate CFML code to accomplish those tasks.
Your model can be almost entirely in Tartan, or in a custom model that you've created to handle your application's needs... but, really, you need to take a more artful and less scientific approach... keeping in mind that there's science in art (what's the recipe for Red Ochre as a paint color?) but it's up to the artist to take those bits of science and assemble them into something meanignful.
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
Hope that helps...
Laterz, J
-- --------------- ------------------------------------- Buy SQLSurveyor! http://www.web-relevant.com/sqlsurveyor Never make your developers open Enterprise Manager again.
----------------------------------------------------------
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]
