This is where AOP (aspect-oriented programming) would probably come into play. But be warned, this is one of those things that (at least for me) was quite confusing when I first started using it. The gist of it is that you can define a CFC that will "wrap" your real CFC (a DAO in this case) and provide additional functionality. ColdSpring will dynamically create a component that extends your original component (so that anything depending on the type will be satisfied), but you will then have the ability to write code that you want to run before or after the method is called on your real DAO. Logging is kind of the "poster child" use case for AOP. I believe Chris has some blog entries about AOP, and the LightPost (LitePost?) sample app I believe uses AOP so maybe that would help to kick around.
On Nov 5, 2007 8:17 PM, Mike Kear <[EMAIL PROTECTED]> wrote: > Thank you all for your ongoing help on this. I can see you're all trying > to keep it plain speaking and not use too much OOP jargon and I do > appreciate that. > > > > There are some new concepts for me to grasp in all this and I think I need > to re-engineer my current project for the umpteenth time, but each time I > do, it's becoming clearer and I think Coldspring is doing more of the heavy > lifting. It's really nice not to have to worry about how to instantiate > a CFC all the time. In the past, I was forever opening a CFC to look at > the init method to check what was required. Then I started using a > factory CFC I wrote, and that eased that problem, but with Coldspring I > can see it's going to be a much more elegant way to do this. With > Coldspring I can see I just call a cfc in my code and there it is, all > initialised and ready to use! > > > > Neat. > > > > In the past I've passed in the user information for my audit trails by > putting it as part of the method call or when instantiating the cfc – e.g > . > > > > <cfset ProductsDAO = application.cfcfactory.getDAO( session.userbean, > "productsDAO") /> > > > > But it is a lot more elegant if coldspring can provide a productsDAO > complete with knowledge of who the person is calling it up and anything else > it needs to know.. > > > > I think I almost understand the concept of a façade now. I hope you'll > all be patient with me as I learn. > > > > I just wanted to say thanks. It's great to be doing this with some of the > most knowledgeable people in the CF world in my corner with me. > > > > Cheers > > Mike Kear > > Windsor, NSW, Australia > > 0422 985 585 > > Adobe Certified Advanced ColdFusion Developer > > AFP Webworks Pty Ltd > > http://afpwebworks.com > > Full Scale ColdFusion hosting from A$15/month > > > > > > > ------------------------------ > > *From:* [email protected] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Peter Bell > *Sent:* Monday, 5 November 2007 1:24 PM > > *To:* [email protected] > *Subject:* [coldspring-dev] How do I inject a userbean into a DAO? > > > > I'm pretty sure he meant one DAO per business object (although I could be > wrong – you can create a "generic" DAO with parameterized CRUD methods so > it'd only have four methods and each would work with any table). Most people > have more or less one DAO per table, but even with 40 or even 100 tables, > that isn't so many objects – having 100 DAOs in memory is not likely to > become a performance bottleneck – neither will instantiating 40 or 100 of > them on a single page load on application start, although if you're > concerned, use lazy loading and depending on your dependency chains that may > mean they won't all be instantiated on app load. > > Best Wishes, > Peter > > > On 11/4/07 8:32 AM, "Mike Kear" <[EMAIL PROTECTED]> wrote: > > Wow that could end up with pretty humungous sized DAO then – if I have 40 > tables on the site, I will have somewhere close to 40 'create', 40 'read', > 40, update, and 40 delete methods, plus all the other ancillary methods like > init and setservice, etc that set it all up and make it work. > > In fact I just counted the tables in the site I'm working on at the moment > and there are currently 47 tables on that database, and the task I'm working > on now will require an additional 6 tables. > > A CFC with 160-170 methods doesn't sound too workable to me. Do you > honestly have only one DAO for your whole web site?? I was working on the > assumption that I should have more-or-less a DAO for each table. Not > exactly 1-1 relationship because sometimes it's easier to have multiple > tables worked by one DAO, but 47 of them?? Really? > > Cheers > Mike Kear > Windsor, NSW, Australia > 0422 985 585 > Adobe Certified Advanced ColdFusion Developer > AFP Webworks Pty Ltd > http://afpwebworks.com <http://afpwebworks.com/> <http://afpwebworks.com/> > Full Scale ColdFusion hosting from A$15/month > > > > > > ------------------------------ > > *From:* [email protected] [ > mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > *On Behalf Of *Derek P. > *Sent:* Sunday, 4 November 2007 1:07 PM > *To:* [email protected] > *Subject:* [coldspring-dev] How do I inject a userbean into a DAO? > > > When you say "a whole bunch of singleton DAOs", what do you mean? You > should only ever create one singleton DAO for your *entire* application. > > > > - Derek > > > > > On Nov 3, 2007, at 3:44 PM, Mike Kear wrote: > > > Brian, Please don't ask me that. You're knowledgeable about OOP > techniques, I'm only just learning. Instead of asking me a question like > that, with an implied criticism embedded in it, why don't you just suggest a > better way instead. > > In my view, there are two things that make OOP so difficult to understand > for people who learned coldfusion in the procedural school – the esoteric > arguments back and forth and the huge pile of technical terms. I even get > the feeling that there are some people that just make up their own technical > terms and use them as though we're all supposed to know what they are and we > must be dummies if we don't. There is one leading blogger in the CF world > who makes a LOT of statements about OOP but I have to confess that in spite > of reading at least 50 of his posts, there isn't a single one that I > understood. He might as well have been posting in Latin for all the good > it did me. > > So why I would do it the way I did? > > I figured it was wasteful of resources to just create a whole bunch of > singleton DAOs on the off-chance that someone might need to use them. I > thought a better approach was to instantiate the DAO when someone went to > the area of the admin module that is going to require this DAO. I > instantiated the DAO at the top of the page that requires it, and reused it > muitiple times down the page. > > Somene else suggested I just access the session.userbean as and when I > required it, directly from the DAO. I thought that was BAD BAD BAD. I > thought the notion of encapsulation meant no cfc should have to look outside > itself for anything. I thought the DAO should be given anything it needs to > know. Well in this case, any cfc modifying the database in any way has > to have a stamp on the record it changes or adds. . I need to stamp it > with the time (can't use getdate() in the database because that's not > Australian Eastern Standard Time – so I pass in the current AEST) and the ID > of the user making the change. > > So that's the problem I'm trying to work out … how do I inject the > userID into the DAO so it can use it? > > I'm afraid I'm still not too sure how I persuade Coldspring to give me a > DAO initialised and ready to use, complete with the userid and time (I > normally use request.austime – a variable I create in the OnRequest() > method of the application.cfc > > Cheers > Mike Kear > Windsor, NSW, Australia > 0422 985 585 > Adobe Certified Advanced ColdFusion Developer > AFP Webworks Pty Ltd > http://afpwebworks.com <http://afpwebworks.com/> <http://afpwebworks.com/> > Full Scale ColdFusion hosting from A$15/month > > > > ------------------------------ > > *From:* [email protected] [ > mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > *On Behalf Of *Brian Kotek > *Sent:* Sunday, 4 November 2007 4:46 AM > *To:* [email protected] > *Subject:* [coldspring-dev] How do I inject a userbean into a DAO? > > A more fundamental issue is: why would you want to create a new instance > of the DAO on every request instead of using it as a Singleton? > > > > > >
