Thanks.
I've been working on just writing what I need to get a certain job done
and making things simple and generic. That seems to be helping me not
get too overwhelmed with writing every possible bit of code under the sun.
I started with a simple Manager & ManagerHome system (someone was
coaching me through the basics) but I think I will add a ManagerDao and
a ManagerGateway. I've heard of "one click one action" and I'm starting
to think that OO has kind of a "one function one action" phylosophy.
I'll check out the link when his site comes back up though. Thanks
Joelle
Nando wrote:
Joelle,
It can take a while to get your head wrapped around OO. If you haven't
read any introductory books, i'd definitely start there. That said,
once you begin to understand the theory of it, you'll need to figure
out how to practically apply it, and specifically in CF.
My number one tip is to keep your feet firmly on the ground. Stay
practical. It's easy to imagine all kinds of Objects in your problem
domain in the beginning and wonder how they are all related.
Composition, Inheritance, Has A, Is A ... Managers may own (have)
Projects and Projects have Managers and Workers and Managers have
Workers and Workers have Managers AND Assignments. How the hell do you
model THAT??? It seems like a tangled mess.
Stay on the ground and take it one step at a time. When your
application is editing a Project, is it editing a Manager /at the same
time? /If the answer is no, then you most likely don't need to build
that relationship into your model. Especially when you are just
beginning. Use a Gateway Object (ManagerGateway) to fetch the Manager
Names and ID's for your form, and take that foreign key and use your
ProjectDAO to persist it in your database.
So for this little piece of your app, where you edit/add Projects, i'd
use these objects:
Project - a bean to hold and pass around your Project data
ManagerGateway - a gateway object that just returns queries ...
ProjectDAO - an object specifically for persisting Projects to the
database, with CRUD methods create, read, update, and delete.
There are more sophisticated approaches, but this would be a simple
outline to follow to get you started. Beans, Gateways, and DAO's.
You would get the data for your reports from a Gateway. In essence, a
Gateway simply wraps your queries in a function and makes it available
to your whole application from one place.
AssignmentGateway.cfc could have a theoretical method called
"getMyReport()" that returns a query that joins your Worker, Manager,
and Assignment tables with an appropriate where clause. getMyReport
could also take an argument, or several arguments (similar to passing
an attribute into a custom tag) that modify the where clause of your
query.
Joe Reinhart has some excellent tutorials on OO in CF on his site,
http://clearsoftware.net/ (once he gets it back up again - you'll need
to wait a day or so ... ).
----------------------------------------------------------
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]
