Johnathan, you said 'This way my application code never directly accesses the BEAN or DAO objects'
I'm in agreement your app shouldn't talk to your DAO but why not the bean? Surely myBean.validate() , myBean.getFirstname() etc are ok. Using something like myService.getFirstname(myBean) looks strange and pontless. I use a service object to create/get a bean (it itself calls a bean factory) but once I have my bean I talk to it directly. If I've misunderstood your post let me know! Alan ________________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of Jonathan Hall [EMAIL PROTECTED] Sent: 26 August 2008 03:21 To: [email protected] Subject: [CFCDEV] Re: CF, DAOs, CRUD and OO 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]<mailto:[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 -~----------~----~----~----~------~----~------~--~---
