On 6/29/06, Baker,Jonathan <[EMAIL PROTECTED]> wrote:
In an earlier post, Craig responded to a question by saying "Personally,
I consider putting view controllers in session scope to be a pretty bad
idea, and would
lean towards making this a restriction. (Putting non-view-controller
backing beans in session scope to save state across sessions is fine.)"
(The whole post is included below if you're interested)
This makes sense if a ViewController is our in-memory object
representation of a page, since a page only lasts for one request.
Well, I was looking at the Shale samples and in the rolodex example, the
ViewController (backing bean) for the rolodex is stored in session
scope.
<managed-bean>
<description>
View controller for the JSP view rolodex usecase
</description>
<managed-bean-name>rolodex</managed-bean-name>
<managed-bean-class>
org.apache.shale.usecases.rolodex.Rolodex
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
I understand that samples don't have to reflect best-practices, but I'm
curious as to what the best-practice would be.
Good catch :-). I suspect the use case here was maintaining some view
state information across requests -- right, Gary?
Should your ViewController object be in request scope, and get injected
with a non-view-Controller that could live in any scope. The
non-view-Controller can have model objects injected into it. This way
the ViewController can handle all view related methods, and pass through
to the non-view-Controller for business methods which then get passed on
to the model objects.
That's the way I'd probably do it, especially if I had prebuilt model and
business logic objects. A benefit of this is that your non-VC beans don't
have to have any API dependency on the web tier at all ... making it much
easier to unit test in isolation, or reuse in other application
environments. If these non-VC objects are managed beans, you can also use
the setter dependency injection mechanisms to configure *them* as well.
Should your ViewController object live in request scope, and just get
variously scoped model objects injected, and after that just work as
both a View and non-view Controller.
This works ok for simple apps, but can lead you down a "mixing of concerns"
path that makes life more complicated in larger scenarios. The
corresponding question for Struts 1.x would be "do I put my business logic
directly into my Actions, or do I abstract it out into separate classes?"
The general wisdom is that you *should* separate things, but you'll often
see small (and sometimes not so small) apps that mix.
Shoud you do something else completely different from either of those
two scenarios?
JB
Craig
