Hello,
I was about to write the same reply as Christian.
To go further, compare
// ANNOTATIONS OMITTED FOR BREVITY
class MyController {
@Autowired
private UserService userService;
public ModelAndView prepareUser(Integer userId) {
ModelAndView modelAndView=new ModelAndView("/editUser.jsp");
modelAndView.addObject("user",userService.getUser(userId));
modelAndView.addObject("countries",userService.getCountries());
modelAndView.addObject("profiles",userService.getProfiles());
return modelAndView;
}
}
// ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
class MyActionBean extends BaseActionBean {
@SpringBean
private UserService userService;
private User user;
private List<Country> countries;
private List<Profile> profiles;
public Resolution prepareUser() {
user=userService.getUser(user.getId());
countries=userService.getCountries();
profiles=userService.getProfiles();
return new ForwardResolution(""/editUser.jsp");
}
}
Stripes-style has the virtue of being type-safe compared to Spring MVC
("user","countries"...): less error prone, easier to unit test. On the
contrary, Spring Controllers are "singletons" whereas Stripes Actions
are "prototypes": Spring-style is probably faster because dependency
injection is done only once.
Gérald
2011/3/3 Poitras Christian <christian.poit...@ircm.qc.ca>:
> Hi Tony,
>
> Personally, I would code the action bean differently making it look almost
> exactly like the Spring version.
>
> // ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
> class MyActionBean extends BaseActionBean {
>
> private User user;
>
> Resolution deleteUser() {
>
> userService.deleteUser(user);
> return new RedirectResolution("/listUsers.jsp");
> }
>
> Resolution addUser() {
>
> userService.addUser(user);
> return new ForwardResolution("/showUser.jsp");
> }
> }
>
>
> Is there anything wrong in getting the whole user object to delete it instead
> of just the id?
> That's even more trivial to do if your user converter takes the id.
>
> Christian
>
> -----Message d'origine-----
> De : Tony Drago [mailto:do...@mailinator.com]
> Envoyé : March-03-11 4:52 AM
> À : stripes-users@lists.sourceforge.net
> Objet : Re: [Stripes-users] re quest/response scoping
>
>
>
> Nikolaos Giannopoulos wrote:
>>
>>
>> Encapsulation in OO IMHO pertains to the class as a whole not the method
>> level. If you want to encapsulate at the method level then your going
>> to have a hard time not allowing someone to access and affect other
>> attributes of the class (e.g. other attributes) as even if you mark
>> attributes as private any method of the class can alter it.
>>
>> Perhaps you might be used to defining classes that should ideally be
>> further refactored into multiple classes. Not sure - but if you could
>> provide some more complex examples then we could examine specifics and
>> dispense with theory or generalized statements (from my side as well) ;-)
>>
>
> Thanks for the response. You asked for a specific example, so here you
> go.....
>
> An action bean which creates and deletes users. IMO, these two actions
> belong to the same bean, but in the case of add we need all the User
> properties, but in the case of delete we only need the id. In Spring the
> controller would look like this:
>
> // 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);
> }
> }
>
> In Stripes the action would look like this:
>
> // ANNOTATIONS, GETTERS AND SETTERS OMITTED FOR BREVITY
> class MyActionBean extends BaseActionBean {
>
> private Integer userId;
> private User user;
>
> Resolution deleteUser() {
>
> userService.deleteUser(userId);
> return new RedirectResolution("/listUsers.jsp");
> }
>
> Resolution addUser() {
>
> userService.addUser(user);
> return new ForwardResolution("/showUser.jsp");
> }
> }
>
> >From a readability point of view I much prefer the Spring MVC code because I
> can tell without looking at the method body, what parameters are used by
> each handler/event. In the case of Stripes, I have to read the body of each
> method to figure out whether userId/User are used as request parameters or
> view model by each event.
>
> I feel like the Stripes approach is poorly encapsulated because
>
> - public getters/setters must be defined for userId and User, but these
> should only be accessible to the event handler that needs them
> - the view model produced by a handler also must have public
> getters/setters, but this model should really only be visible to the view
> (JSP)
> - there is no way to prevent one handler/view from attempting to access
> parameters or view data intended only for use by another handler in the same
> bean
>
> Again, I'm not attempting to "prove" that SpringMVC is better than Stripes,
> the question of interest is whether Stripes encourages bad practice from an
> OO point-of-view?
>
> (Incidentally, a nice side-effect of SpringMVC's approach is that there's no
> need to write boilerplate getters/setters for the request parameters, though
> I guess I could eliminate these by writing my Stripes action beans in
> Groovy)
>
> --
> View this message in context:
> http://old.nabble.com/request-response-scoping-tp31050264p31057415.html
> Sent from the stripes-users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
> ------------------------------------------------------------------------------
> 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
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
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
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
