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]
