Personally I keep session out of the model. Why? Because if I call my model using a web service, there IS no session scope. As such I treat sessions as a controller responsibility - along with the form and URL scope. As with all design decisions, it depends what use cases you need to support. I have to put a little more code in my controller which acts as an adaptor to a standard security implementation in the model which is session scope independent, but it means I can support implementations without session scope just by adding a new controller type.
Best Wishes, Peter On Apr 29, 2008, at 1:48 PM, Brian Kotek wrote: > See, you agree with me and don't even realize it. ;-) Your second > approach would be the one I would recommend. Yes, something, > somewhere has to know about the session scope or you can't use it. > Which is why the SessionFacade is the common way to solve the > problem. You can encapsulate access to the session scope in a single > method (i.e. getCurrentUserID() would be the only thing that knows > about the session scope, and everything else calls that method), or > you can even create a whole component to encapsulate access to the > session scope if you're OK with the tradeoffs in doing so. > > Another issue the choice to enforce security at the Controller level > at all. What happens when you want to open this up to a Flex > application? Or to web service calls? Those things never even see > your HTML Controller. As things go ever more toward SOA, this kind > of decision can really cause problems later. I'd recommend enforcing > such security in the Model as much as possible, either through > explicit code or via AOP. > > That said, of course if your controller has to do something like > forward the user to a login page (i.e. it is making a decision > specific to the HTML application), then by all means do so. I'd do > something along the lines of: > > <cfif not securityService.isUserLoggedIn()> > <cflocation.../> > </cfif> > > Even in that case, the Controller has no idea *how* the security > service knows whether the user is logged in or not. For all it cares > you're writing it to a text file. ;-) > > > > On Tue, Apr 29, 2008 at 1:23 PM, Jon Messer > <[EMAIL PROTECTED]> wrote: > I'm not sure I agree with you here Brian, I do agree that for most > purposes persistent scopes shouldn't be accessed by objects, but I > think session and controller are a little different. > > Going with the session.userId example, where would the this be set > or accessed? > > It seems to me that if you are going to use the concept of session > then either the controller can do something like > > if(securityService.isUserLoggedIn(session.userId) ) > > or else the securityService itself would have to know about > session.userId. But either way one of these two things has to know > about it or else you can't use session at all. > > I agree 100% that the shared scopes shouldn't be used as a hidden > means to pass information to and from objects. And controllers > definitely have no business needing a dsn, but if they did it should > be passed to them on init not accessed through application. > > I'm just not sure where you see something like session.userId being > set/used. I think of session as a form of user input cached for > convienence. And the controller is supposed to mediate user input to/ > from the model. > > I could be persuaded I'm wrong though, if you describe how you would > handle this situation in a better manner... > > > > On Tue, Apr 29, 2008 at 9:54 AM, Brian Kotek <[EMAIL PROTECTED]> > wrote: > As the person pushing this in the CF-Talk thread, I have to disagree > with Dan on this one. Though I think he may be misunderstanding the > question. Dan, to be clear, the issue isn't whether it is OK for a > Controller CFC to use values *passed-in* via a method call or > constructor, which I agree is fine and is in fact the way it should > almost always be done. He's asking whether it is literally OK to > directly reference "application.dsn" or something from within a > Controller, which I would say no to. > > I don't see any reason why a Controller CFC should need to access > anything in the application or session scopes, or anything external > to the component for that matter (meaning anything not passed as > arguments to the method or properties of the component). > > In fact, I'd argue that in most cases, if you think you need to > access an application or session variable from inside a Controller, > it means you may want to reconsider what the Controller is doing in > the first place. Things like "application.dsn" or "session.userID" > should probably never be needed by a Controller. These things are > used by the Model, and the apparent need for these kinds of values > may indicate that your Controller is doing work that should really > be happening in the Model anyway. My Controllers are really, really > dumb. All they do make requests to the Model to perform processing, > and render Views. > > regards, > > Brian > > > > > On Tue, Apr 29, 2008 at 12:03 PM, Charlie Griefer <[EMAIL PROTECTED] > > wrote: > > Hey all... > > I've had a lingering question, and a thread over on cf-talk (about > properly encapsulating CFC methods) has really got me thinking about > it. > > Over on that thread, there's a "debate" (to use the term loosely) on > accessing the application scope from within a CFC. Yes, I understand > that's a "bad thing" and I understand why. But in an MVC framework... > what about CFCs in your controllers? Those CFCs don't really model > any particular object. They're more of a transport mechanism to > facilitate communication between the model and the view. > > So, I get that CFCs in the model should be encapsulated. But what > about CFCs in the controller? is it "acceptable" (which i realize is > a subjective term) to access shared scopes like application and > session from controller CFCs? > > -- > Evelyn the dog, having undergone further modification pondered the > significance of short-person behaviour in pedal depressed, > pan-chromatic resonance, and other highly ambient domains. "Arf," she > said. > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
