Matthew, One thing to keep in mind when entering the object oriented sphere:
Many aspects of programming are exact, there is only one right way to do it. Everything else won't work. For instance, an attribute to a function may be required. Perhaps the data passed into the function must be of a particular type, or one of a list of specific choices. A programmer is used to thinking in this way and dealing with that exactness. OO isn't exact like this. I find I'll go along with one way of doing things in one project, and try something else in the next. There is no right way to architect an application, far from it! I know that's repeated often, but I find it useful to distinguish between the many tasks we accomplish where there is often only one way it'll work (an error is thrown otherwise), and the tradeoffs and flexibility that are part of the OO landscape. As your OO programs become increasingly complex, there is perhaps more and more of a difference between good choices and bad choices, but you'll be able to distinguish those more easily when you get there. For now, feel free to make your own choices so far as architecture goes. I won't even call them mistakes when you discover that what you've done has backed you into a corner and that there is a better way (in a particular context). We're all continuously learning from the architectual choices we make, and that learning process continues for quite awhile, probably for a whole career ... ... which is very different from the learning process involved with dealing with the more exact parts of programming. Once you understand how to code a tag, you're done, you've got it. OO isn't like that. On Wed, Aug 27, 2008 at 11:24 AM, Alan Livie <[EMAIL PROTECTED]>wrote: > > Yip, your approach is pretty much how I do it. > > 1) getUser() is called in UserService() ( we could also be talking about an > AuthenticationService here but lets keep it simple :-) ) > 2) the getUser() method creates a new User bean / business object and sets > the username and password properties > 3) It then delegates to your UserDAO's read() method, passing it the bean. > 4) UserDAO's read() method runs the sql SELECT * FROM users WHERE ..... > query. > 5) If a record is found it converts the record into a struct and runs > init() on the bean, passing it the struct. The read method returns void. > 6) The UserService's getUser() method returns the loaded bean > > As far as the bean's validate methods are concerned I only use them before > saving the bean. ie if the html form is processed I init() the User bean > with the form data, call UserService.save(User) which does an <cfif > User.validate() then UserDAO.save(User). The service returns a result > (either a Result object that Brian uses or an array of structs with all the > error info on field, message, error type etc) This lets you either redirect > the user back to the form, show the errors or to a success page etc. > > If the validation for Users and Administrators was different your > validate() method could do an <cfif IsAdministrator() > validateAdministrator() etc. Your validate() method would also call > isPasswordValid() etc > > Your question about what if no records are returned is worth looking at. My > usual use case for the above process is calling getXXXX() and passing it an > id so it should find a record. I think for login stuff an > AuthenticationService is a good thing that just concentrates and getting > username and password, calling UserGateway. If one record is returned, the > authenticationService returns true, else it returns false. Then your > controller method can redirect to login page or go to the page its meant to > be going to. > > Hope this makes sense. Its worth remembering this is just one way of doing > it and it seems to work fine for me. A friend of mine runs save() from his > bean rather than his Service and injects DAO's into his beans. It works well > for him so he's sticking with that. > > Alan > ________________________________________ > From: [email protected] [EMAIL PROTECTED] On Behalf Of > Matthew [EMAIL PROTECTED] > Sent: 27 August 2008 05:23 > To: CFCDev > Subject: [CFCDEV] Re: CF, DAOs, CRUD and OO > > Hi Alan > > Thanks for the detailed response - very helpful. > > Just one question regarding "Your User.cfc bean / business object > would enforce your business rules, ie isPasswordValid(), > isAdministrator(), validateUser()..." I don't get how this would > work... let me paint a picture of how I understand it working (lets > forget about the factory for now); > > 1. Call getUser() in UserService (passing in username and password for > validating) > 2. So does the UserService call validateUser() in UserBean... but I > though Beans are objects with just getters and setters (i.e. no > querying). > I thought the process would have been: > 1. Call getUser() in UserService (passing in username and password for > validating) > 2. UserService init's a UserBean (passing in username and password) > 3. UserService passes UserBean to Read() in UserDAO (passing in an > half-baked-bean) > 4. UserDAO runs query looking for record (calls getUsername() and > getPassword() from the half-baked-bean which was passed in). > 5. If a record was found then re-run the Init() function on the half- > baked-bean passing in query results as arguments i.e. if > (q.recordcount) { arguments.userBean.init(q.Firstname,q.Lastname)} and > then return the fully-baked-bean. > 5b. I'm not to sure what you should do if no recordcount. Perhaps this > is your point that you return the bean to UserService regardless and > then run validateUser() on UserBean to check that it's a fully-baked- > bean. > Am I way off? > Cheers > Matthew > > > > > -- Nando M. Breiter The CarbonZero Project CP 234 6934 Bioggio Switzerland +41 76 303 4477 [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
