On Mar 3, 2011, at 1:52 AM, Tony Drago wrote:
> // ANNOTATIONS OMITTED FOR BREVITY
> class MyController {
>
> public String deleteUser(Integer userId) {
>
> userService.deleteUser(userId);
> return "redirect:/listUsers";
> }
>
> public ModelAndView addUser(User user) {
>
> userService.addUser(user);
> return new ModelAndView("/showUser", user);
> }
> }
>
And here's where it fails. The KISS idiom is paramount here. Stripes Action
Beans are (typically) small enough where the encapsulation simply isn't
necessary, and in fact gets in the way because, as others have mentioned, when
you're working with many similar methods, pretty soon, they all have similar
signatures. While it's explicit, it's redundant.
Also, MVC REQUIRES this style because the controller is not thread safe. IMHO,
the fact that Servlets are not thread safe makes sense to me from a simplicity
of the implementation and design of the basic framework. The fact that other
frameworks KEEP that "feature" is, frankly, just insanity. ActionBeans are
created (typically) fresh with each request, so they don't need to encapsulate
logic and parameters at the method level, the Class is the level of abstraction
and encapsulation.
With Classes we get neat things like inheritance. We have a large chunk of
refactored code and handlers in our system that is shared among our
ActionBeans. Our Entities have common ancestry, which our factored out routines
and resolutions can work with. But Stripes binds to the Entities themselves,
correctly. So, our ActionBeans might have List<User> in them, while the common
code works with List<Entity>. With Methods as your sole level on encapsulation,
you can't have a handler that takes "List<Entity>" because you'll lose the rest
of your model when the system binds to it. Since our binding is done at a
higher level, in the class, we can bind to List<User> and then call a
resolution and treats them as List<Entity> without losing information. You lose
that kind of flexibility when Methods are your sole level on encapsulation.
Stripes use of the "ActionBean as Controller/Model" also fits well in the 90%
use case. The simple fact that you're populating your "ModelAndView" is
something that Stripes doesn't have to do. Every method has to enumerate its
parameters (redundantly in the 90% use case), and then enumerate the objects
going in to the ModelAndView, again, in the 90% use case, redundantly. Stripes
factors all that boiler plate away. This, IMHO, simplifies the code.
I'll be the first to admit that on edge case, with really complicated
ActionBeans, it can get a little busy. Also, Stripes potentially lets other
things that we don't want populated, to be populated (i.e. some piece of the
model not used by the resolution). But, I'd rather deal with that rare bit of
busy than fight the repetitive, redundant boiler plate in the 90% case.
There's little stopping folks from writing redundant, wordy code (because, as
we all know, Java isn't wordy enough) with Stripes. *I* embrace the fact the
Stripes lets me NOT do that. Expedience and practicality in the every day work
outweighs design purity every time in my book.
Regard,
Will Hartung
"Bulldozing Ivory Towers since 1979"
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
