After having somewhat "mastered" Struts 1.x, and with all the other competing frameworks out there, why should I spend time learning Struts 2? And why not stay with what I know: Struts 1?
From some perspective sticking with what we already know is a perfectly acceptable solution and may suit our needs just fine. Of course, we could say the same thing about COBOL or PL/1, too ;)
As far as competing frameworks go, sure, there are several other viable options along with Struts 2. All have their advantages and disadvantages. Each may be more, or less, appropriate depending on various criteria, perhaps project- or environment-specific.
From an architectural and cleanliness standpoint regarding Struts 1 v. Struts 2, however, IMO Struts 2 comes out way ahead. For me the biggest improvements were testability, type conversion, and a better separation of concerns, although that can depend on how the Struts 1 application was developed.
This last bit is anecdotal, but I've been using Struts 1 since 1.0. I've now been using Struts 2 since the XWork changeover, and I wouldn't even consider using Struts 1 for a new project--the benefits of Struts 2 are just too great. I'm comfortable recommending Struts 2 to others as well; the Apache community is solid and stable. That doesn't mean there aren't other Java-based frameworks worth considering, of course.
Hi , there are some diffrences between Struts 1 and 2 , check this and this
Scotty Boy Sinclair
Joined: Sep 11, 2008
A BIG benefit of struts2 for me was calling getters of the action object in a clean way.
Typically in a web MVC application the execute() method has to work out the view requirements based on the request/session parameters and then load the data from the database acordingly. The view is then generated via JSP which then uses the preloaded objects.
This is bad imo because the view requirements (as captured in the JSP) is duplicated in the execute() method logic.
But since struts2 allows you to call any action getter from the view. The view can drive the data retrieval requirements by making the action perform lazy loading in each getter method. This also makes the actions more reusable since they are less view specific.
I find this very powerfull especially if you have complex user specific views.