Spring MVC Web Framework versus Struts

[biguniverse]

I realize the benefits listed below are good reasons to go with Spring MVC over Struts but how popular is Spring MVC and how much is it actually being used out there?

I realize why Spring's IOC is popular (and I personally love the dependency injection paradigm); however, for web frameworks is it better to go with Struts at present then to take a risk using Spring MVC? I'm afraid that with sub-projects like Web Flow, the Spring MVC Web Framework might be stable but still work-in-progress (I realize webflow is built on top of Spring MVC).

Being a consultant, I'm always concerned about skill set a customer has in-house from a maintenance perspective, so I'm either considering a "Spring MVC <> Spring IoC <> Hibernate" combo or "Struts <> Spring Ioc <> Hibernate".

Any advise would be appreciated.

[BENEFITS]
1. Spring provides a very clean division between controllers, JavaBean models, and views.
2. Spring's MVC is very flexible. Unlike Struts, which forces your Action and Form objects into concrete inheritance (thus taking away your single shot at concrete inheritance in Java), Spring MVC is entirely based on interfaces. Furthermore, just about every part of the Spring MVC framework is configurable via plugging in your own interface. Of course we also provide convenience classes as an implementation option.
3. Spring, like WebWork, provides interceptors as well as controllers, making it easy to factor out behavior common to the handling of many requests.
4. Spring MVC is truly view-agnostic. You don't get pushed to use JSP if you don't want to; you can use Velocity, XLST or other view technologies. If you want to use a custom view mechanism - for example, your own templating language - you can easily implement the Spring View interface to integrate it.
5. Spring Controllers are configured via IoC like any other objects. This makes them easy to test, and beautifully integrated with other objects managed by Spring.
6. Spring MVC web tiers are typically easier to test than Struts web tiers, due to the avoidance of forced concrete inheritance and explicit dependence of controllers on the dispatcher servlet.
7. The web tier becomes a thin layer on top of a business object layer. This encourages good practice. Struts and other dedicated web frameworks leave you on your own in implementing your business objects; Spring provides an integrated framework for all tiers of your application.

[Rod Johnson]

Some quick thoughts.

I'm afraid that with sub-projects like Web Flow, the Spring MVC Web Framework might be stable but still work-in-progress

SWF is as much of a challenge to Struts and co. as Spring MVC. It has no impact on the stability of Spring MVC.

Another point to consider: migration from Struts to Spring MVC is pretty straightforward, as Struts Actions often translate easily enough to Spring MVC Controllers.[/quote]

[roadbugcz]

And that is status of declarative validation in Spring. I've been searching a bit and it seems there are 2 possibilities, one is jakarta commons validator and the second is Valang, both of them seem to be in the sandbox.

I'm not sure how usable/stable are these two at the moment. Have anybody used them in production? Any good/bad experience? Any informations welcomed.
Thanks a lot,
Mirek

[Keith Donald]

To second Rod here:

Spring Web Flow (SWF) is not built on top of Spring MVC: the two framework compliment each other in a loosely coupled manner. More specifically, Spring MVC can delegate to SWF for flow execution via a thin adaption layer, and that's how it's always been designed (and will stay that way).

SWF is a pure controller framework focused primarily on solving the problem of managing stateful web conversations (dialogs) in a elegant manner, providing a self-contained flow engine based on a finite-state machine.

Spring MVC is a request-driven MVC framework positioned very much as a Struts+1, with a more complete data binding facility and more extensibility points than what's offered by Struts.

SWF fills the "C" in the MVC -- SWF is not a replacement for Spring MVC, it's a "C" compliment.

Keith

[andree]

hi,

Keith writes that Spring MVC has more extensibility points. Is there someone who could give a short sum about which extensibility points are given by Spring MVC?

thx
andree

To second Rod here:

Spring Web Flow (SWF) is not built on top of Spring MVC: the two framework compliment each other in a loosely coupled manner. More specifically, Spring MVC can delegate to SWF for flow execution via a thin adaption layer, and that's how it's always been designed (and will stay that way).

SWF is a pure controller framework focused primarily on solving the problem of managing stateful web conversations (dialogs) in a elegant manner, providing a self-contained flow engine based on a finite-state machine.

Spring MVC is a request-driven MVC framework positioned very much as a Struts+1, with a more complete data binding facility and more extensibility points than what's offered by Struts.

SWF fills the "C" in the MVC -- SWF is not a replacement for Spring MVC, it's a "C" compliment.

Keith

[klr8]

Check the Reference documentation for Spring MVC:
http://static.springframework.org/sp...rence/mvc.html

It discusses things like HandlerMappings, HandlerInterceptors, ViewResolvers, ...

Erwin

[alejandrogarciaseco]

To second Rod here:

Spring Web Flow (SWF) is not built on top of Spring MVC: the two framework compliment each other in a loosely coupled manner. More specifically, Spring MVC can delegate to SWF for flow execution via a thin adaption layer, and that's how it's always been designed (and will stay that way).

SWF is a pure controller framework focused primarily on solving the problem of managing stateful web conversations (dialogs) in a elegant manner, providing a self-contained flow engine based on a finite-state machine.

Spring MVC is a request-driven MVC framework positioned very much as a Struts+1, with a more complete data binding facility and more extensibility points than what's offered by Struts.

SWF fills the "C" in the MVC -- SWF is not a replacement for Spring MVC, it's a "C" compliment.

Keith

Impossible to explain better, I totally agree.

[chuisman9955]

Spring MVC is much easier to use and maintain than struts in my opinion (I've been using struts for the past 3 years).

And that is status of declarative validation in Spring. I've been searching a bit and it seems there are 2 possibilities, one is jakarta commons validator and the second is Valang, both of them seem to be in the sandbox.

I'm not sure how usable/stable are these two at the moment. Have anybody used them in production? Any good/bad experience? Any informations welcomed.
Thanks a lot,
Mirek

I really like Valang it is quick and easy to use, although I am having problems creating a custom function (http://forum.springframework.org/sho...hlight=valang).

I need to vaidate certain things such as email addresses, zip codes, and phone numbers but out of the box this does not yet seem possible, and like I said I'm having difficulties creating a custom function.

[kris_lander]

I'm currently using Spring MVC (with Webflow) in anger (i.e. on a commercial app) for the first time.

Most of major advantages have already been mentioned, but I have found being completely view independent very useful. It's easy to use any view technology you please. Further more it's possible to use multiple view technologies at the same time which very little hassle which has been very useful on the current project I'm working on.

Being able to declare a Controller just like any other Spring bean is also very powerful and if you use your imagination a bit there are some interesting things you can do. For example, a Spring feature I have taken advantage of with my controller declaration is being able to extend from a parent bean controller declaration. E.g.

<bean id="productsViewController" abstract="true" class="com.web.controller.ProductsViewController">
	<property name="validateOnBinding" value="true"/>
	<property name="commandName" value="productCriteria"/>
	<property name="productServicer">
		<ref bean="productServicer"/>
	</property> 
	<property name="commandClass" value="com.web.form.ProductCriteria"/>
</bean>

<bean id="accessoriesProductViewController" parent="productsViewController">
	<property name="successView" value="accessories.view"/>
	<property name="productType" value="accessories"/>
</bean>

It's this sort of seamless integration with the rest of the Spring Framework that gives much more flexibility than Struts IMO.

There are only two reasons I can think for using Struts in a Spring application.

1) You have a lot of developer resources with strong Struts skills and no time to train them up on Spring MVC. (Saying that I think if they can't pick up Spring MVC quickly after using Struts you'd have to question whether you should be employing these resources in the first place!)

2) You have a lot of legacy/core code in Struts that you want to reuse.

So far my experience with Spring MVC has been very encouraging. I think the biggest indicator that it is a superior technology is that I haven't missed any functionality offered by Struts, because there has always been an equal, if not superior equivalent in Spring MVC. On top of that I have discovered many new features in Spring MVC (and even more so Webflow) that I like a lot.

If you are using Spring elsewhere in your application then I would find it very hard to think of a good technical reason to use Struts. I think most objective people consider Struts to be showing it's age, whilst Spring MVC is just getting started.

[rprabhakar]

And that is status of declarative validation in Spring. I've been searching a bit and it seems there are 2 possibilities, one is jakarta commons validator and the second is Valang, both of them seem to be in the sandbox.

I'm not sure how usable/stable are these two at the moment. Have anybody used them in production? Any good/bad experience? Any informations welcomed.
Thanks a lot,
Mirek

Hi

I had a similar question in my mind two months ago and the final choice that came out was Spring Modules. I got it implemented to my application and is working very well.