Hey Mike, 2010/2/23 Mike Teehan <[email protected]>: >> > Example: >> > I have a getUserList() function that queries the db to find all the > users >> > (class User) who can log in. This function lives in the login code. >> > Once I switch to deriving my User from Dbo::Dbo, I can then move >> > getUserList() to be part of the User class, better sharing the >> > functionality. >> > >> > If this is the case, it looks like I have a bit of refactoring to do. >> >> Yes, that is what it is meant for, although the particular example >> getUserList() sounds like it is a static method which will not have >> access to the session(), it is only associated with a particular user. >> The standard use case would be like : > > All this became very apparent as I toyed with class changes last night. > In your experience do you think it would be better to make it a static > member (I don't like static stuff... it scares me) or should I perhaps > make a singleton (per session) UserDB class that can manage that stuff?
Yes, I think such a query should be linked directly or indirectly to your specialized session (like BlogSession). > Its seems in the Blog example that you just put most of the db stuff > right into the view code. Quick and dirty? I agree it would be nicer to move the session_.find<>() calls from BlogView to BlogSession, encapsulated in a specific method. And depending on how you look at it, you could say that BlogSession should be moved to the model/ directory as it is the top-level entity of the model. Regards, koen ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
