IF your administrators and users are in the same db table ie Users and has a
userTypeId column then you would just have a UserDAO that acts on all data.
Think of your UserService as an API and you would possibly have getUser() and
getAdministrator() methods that would pass different userTypeId to the
UserDAO's read() method. It could also have methods like
sendPasswordRequestEmail() that may itself use another object ie a Notification
object to send emails etc (although some may argue this method could also live
in your User bean / business object).
Your User.cfc bean / business object would enforce your business rules, ie
isPasswordValid(), isAdministrator(), validateUser(), validateAdministrator()
and getters and setters to the properties ie getFirstname(), setUsername() etc.
Your Factory is responsible for creating all your objects ie get("UserService")
.. the factory would then create a UserDAO and then create a UserService and
run setUserDAO() on UserService to give it a reference to your UserDAO. This
way all the complicated dependencies are encapsulated in your factory so you
don't have to worry about it elsewhere ie calling get("UserService") you get
your service ready to roll with the DAO available.
Hope this made sense.
Alan
________________________________________
From: [email protected] [EMAIL PROTECTED] On Behalf Of Matthew [EMAIL
PROTECTED]
Sent: 26 August 2008 02:16
To: CFCDev
Subject: [CFCDEV] Re: CF, DAOs, CRUD and OO
Hi Matt
Just to clarify I was asking if it makes sense to have a DAO which has
several "Read" methods - nothing to do with the Gateway debate -
appologies if I wasn't clear.
My question is: say you've got a UserBean and an AdministratorBean,
could you have 1 DAO which talks to both beans i.e. you'd have a
UserAdministratorDAO which has a ReadUser method and a
ReadAdministrator method - my guess is that this is incorrect but I've
seen it a few times and just thought I'd ask. It's my understanding
that each Bean needs a DAO (if the Bean needs to talk to a database).
Perhaps my User/Administrator example is a little poor but is there a
scenerio where a Bean would have more than the 4 CRUD function (plus
an Init() of course).
On another note: can anyone give a description on the difference
between a Business Objects, Factory and Service Layer i.e. does the
Factory live above the Service Layer and is a Business Object a
generic term which encapsulates "Factory" and "Service Layer" or would
you introduce a Business Object Layer below the Service Layer if your
app was big enough to require this extra layer?
Cheers
Matthew
On Aug 26, 10:49 am, "Matt Quackenbush" <[EMAIL PROTECTED]> wrote:
> CRUD is simply an acronym for Create, Read, Update, Delete. These functions
> (methods) are typically found in a DAO (Data Access Object). These four
> methods deal with a single record in a datasource. Some will tell you that
> no "multiple record methods" should be placed in a DAO, while others will
> tell you that it's perfectly fine to do so. Having both single- and multi-
> record methods in your DAO is often referred to as a Table Data Gateway
> (http://martinfowler.com/eaaCatalog/tableDataGateway.html).
>
> Martin Fowler defines a Table Data Gateway as:
>
> "*An object that acts as a Gateway (466) to a database table. One
> instance handles
> all the rows in the table."
>
> *(Emphasis mine)
>
> I personally subscribe to the Table Data Gateway pattern, as it makes zero
> sense to me to have a separate DAO (for CRUDs) and Gateway (for mult-record
> selects).
>
> Hope that helps.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
