I have always thought of it like this:

Bean - Single instance of an object
DAO (TDO) - CRUD (and Gateway) for that Bean
Service - The communication object that executes the DAO for a Bean.

The Service object is what your application code will talk to, it will then
go grab the DAO to run the CRUD for the Bean.   This way my application code
never directly accesses the BEAN or DAO objects, it always talks to the
Service Object.

I have found a couple of RIAForge projects very helpful in grasping this
sort of design.  At the simplest level I will take each of my DB tables and
create a Bean/DAO/Service for them, this isn't always 100% how it will work,
but starting it it really helped me grasp this design pattern.

As for your UserBean & AdministratorBean if those are 2 seperate objects,
you would most likely have 2 seperate DAO's.  But additionally wouldn't an
Admin be a User with elevated access?

Maybe think of it like you would have a CompanyBean/DAO/Service which then
has a UserBean/DAO/Service and those Users could be
admins/superusers/regular users.

Jon Hall

On Mon, Aug 25, 2008 at 8:58 PM, Matt Quackenbush <[EMAIL PROTECTED]>wrote:

> I'm not sure I completely follow the scenario you're trying to lay out,
> since to me an Administrator IS a User, just a different Role than a
> "normal" User.  It all depends upon your design.  I think it is a bad idea
> to have CRUDs for multiple tables living in the same DAO.  Does that answer
> your question?
>
> Your Business Objects are the objects that carry out the business of your
> application.  Examples of such might be: User, BlogPost, ShoppingCart, or
> WebPage.
>
> Your Factory is an object that you call upon to create your various
> Business Objects.  This allows you to have all of your createObject() calls
> in one place, making maintenance simpler.
>
> Your Service Layer is a layer that helps your Controllers and/or Business
> Objects communicate with one another.
>
> There are LOTS of blog posts and articles floating around that discuss all
> of these in much greater detail.  It's a lot to get your mind around, but
> when it finally "clicks", it's pretty cool stuff.
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to