Java开发网 - Struts VS Spring Web

Topic: Struts VS Spring Web

1.Struts VS Spring Web	Copy to clipboard
Posted by: tier3 Posted on: 2004-09-15 19:52 are there any detailed comparison about the the pros and cons between Struts and Spring? I remembered that Mr. floater mentioned a little about it. and it seems Spring is between than Struts in some ways. but I can not find detailed comparison about them in google. Thanks.

2.Re:Struts VS Spring Web [Re: tier3]	Copy to clipboard
Posted by: tier3 Posted on: 2004-09-15 19:54 here are some links from google: http://www.theserverside.com/discussions/thread.tss?thread_id=28442 http://forum.java.sun.com/thread.jsp?thread=546415&forum=54&message=2662219 but not help much.

3.Re:Struts VS Spring Web [Re: tier3]

Copy to clipboard

Posted by: floater
Posted on: 2004-09-16 01:27

1. spring has 1 tag, one interface with one method, while struts has dozens of tags. This is not only an overkill, but also pollute into html world, it increases the learning cost, make html tools hard to use(even dreamweaver adopts this).
2. struts actionforms are intrusive to business objects, they have their own hirachy so we can't have our own hirachy in the business layer. DynaForm has its own problem too, there are redundent small objects everywhere.
3. M in MVC is for model, but the datasource binding in struts makes us to carry this unrelevent object all the way through. Business objects shouldn't care this at all. Struts folks misunderstand this.
4. Struts IoC is not generic at all.

These are just behaviors on the surface(It's just hard to capture all the behaviors because they are changing). There are some fundamental difference on concepts and logic in understand web problems:
1. The dynamic data and structure in HTML: are handled by JSTL, no extra tags needed. Error binding shouldn't interfere with HTML code. Replacing html with customized tags is pretty much like stepping on someone else's toes.
2. The mismatch between HTML form and java OO. All we really need is to match HTML form to java objects. This can be handled by one tag, that's enough, no need for more than 1. Spring does this precisely, while Struts just uses brutal force for almost everything(it has 41,000 lines of source code for tags). It further replaces the form action too.

So we really need just one simple tag for binding and errors. Once we have the java object for the form, we should be back to OO world and do whatever we do there. It should be a simple solution, conceptually. Struts just makes it a big deal, even struts centered solution. It claims that it solves certain problems, but the facts are it solves them with a higher price tag.

Recently, it happened I was dragged by my bosses into this Struts/Spring war. I found most of the struts developers I talked with are not technical matured, short sighted, narrow minded. They just know how to code mechnically, and don't have extensive experience. So I figured this is not just Struts/Spring war, but a war or a coaching on OO and general computer science. This is where I stopped because I don't get paid for this.

4.Re:Struts VS Spring Web [Re: floater]

Copy to clipboard

Posted by: tier3
Posted on: 2004-09-16 09:17

thanks!

about the love of struts, I agreed with you totally.
there are more and more fancy open source projects, such as struts, hibernate, spring, eclipse, and so forth, and more and more developers in china are very interested to master them ONLY, but no understand the technical background of them, and that is OOAD.
Although I am a developer for over 5 years experience, but I am only a beginner of OO modeling and architecture, and I am sure some of guys in mainland are in the same levels as me. Smile

so maybe from now on, we should have to open our eyes, and calm down to spend more and more time on mastering some foreign open source projects, improving our own OO modeling level should be more critical for the whole software development in mainland. Smile

5.Re:Struts VS Spring Web [Re: tier3]	Copy to clipboard
Posted by: floater Posted on: 2004-09-16 22:30 yes, I agree, especially there are some points that are between technical layer and architectual layer, which are always the dabates between architecture group and the folks in the trenches doing the coding.

6.Re:Struts VS Spring Web [Re: tier3]	Copy to clipboard
Posted by: bill1 Posted on: 2004-09-29 08:32 用中文说话好不好.KAO>,吾觉得读英文已经够累了,嘻嘻

7.Re:Struts VS Spring Web [Re: tier3]

Copy to clipboard

Posted by: sunfmin
Posted on: 2004-12-24 16:24

forward a email in struts-user mail list
--------------------------------------------------------------------------------------
Struts design flaw -- ActionForms are not true domain objects
NYIMI Jose (BM Black Eye

Mon, 17 Feb 2003 06:36:44 -0800

Dear Struts Users,

I have just bought this book : "Expert one-one-one J2EE Design and Development" by Rod
Johnson.

http://www.wrox.com/news/852.htm

I will greatly appreciate to have your opinion about this "so beeing design flaw of
Struts" described in the above book.
Rod Johnson suggested an alternative framework that takes strengths of following
frameworks : Struts, Maverick and WebWork, then offer solution to their weaknesses.
Codes are available at :
http://www.wrox.com/dynamic/books/download.aspx?isbn=1861007841#downloads

The Autor wrote the following :

" Despite of its popularity, I'm not a big fan of Struts.It's good enough, but far
from an ideal J2EE web application framework:

* The ActionForm approach - central to Struts request processing model - is
poor. Bean binding is primitive, meaning that only string properties are really
useful. This adds little value over simply querying request parameters.The idea of
copying properties from an action form to business command is inelegant and there is o
support for type checking.

* Struts is too JSP-oriented, although it is possible to use Struts with other
templating technologies.

* Struts is based almost entirely on concrete classes. This makes it hard to
customize Struts's behavior.

* Although things have improved significantly with version 1.1, the Struts
codebase is poor. Not surprisingly, there have been numerous deprecations in moving to
1.1.

* Struts ActionForms have several particularities that we must consider. As all
ActionForms must extend the Struts superclass, they all depend on Struts and the
Servlet API. This means that they can not be passed to business objects, as business
objects shouldn't depend on a particular web application framework or the Servlet API.
Secondly, any request parameters that may contain invalid data (such as numeric
inputs, for which the user might enter non-numeric data) must be matched by ActionForm
properties of type String. The bean manipulation code behind the scenes will attempt
to convert string request parameters to the appropriate type, but any exceptions in
attempting to set properties will result in the org.apache.struts.util.RequestUtils
class failing the request by throwing a ServletException.

* Thus a Struts ActionForm is not a true domain object. It's a place to hold
user data until it can be validated and transferred into domain objects such commands.
The advantage of this approach is that invalid data can be re-displayed easily. The
disavantage is that we will need to get this data into true domain object at some
point, so Struts has only taken us part of the way towards true data binding.

* The need to derive ApplicationForms from a single superclass has always seemed
to me a design flaw. Not only does it tie commands to the Struts framework and Servlet
API, it incorrectly exposes inherited framework properties to update via data binding
from request parameters. For example, adding a servlet parameter with a string value
will break just about any page generated by 1.0 application (with a failure to set a
property of ActionServlet to a string) . Struts 1.1 introduces a workaround for this
particular problem, but the root of the problem is the whole ActionForm concept.

* The ActionForm class also defines a validate() method. Subclasses may override
this method to valid the state of an action form after population from request
parameters. Struts also offers alternative approaches to validation.

* Struts 1.1 corrects many (but not all) of shortcomings of Struts 1.0, for
example by allowing the use of multiple controller servletin application.(The
mechanism for this isn't very elegant, however it's clear that it was an
afterthought). Other enhancement in Struts 1.1 include the introduction of the
org.apache.struts.actions.DispatchAction superclass, allowing several actions to be
performed by the same class. This is very useful in cases where many request types
call for simple handling; it avoids the proliferation of many trivial action classes.
Struts also introduces declative exception handling. "

Thanks a lot in advance for your inputs.

José.

8.Re:Struts VS Spring Web [Re: tier3]	Copy to clipboard
Posted by: floater Posted on: 2004-12-24 21:37 OVer the time, some of these are changing, i.e., Struts folks fix some of the issues, while other issues are hard to fix.

9.Re:Struts VS Spring Web [Re: tier3]

Copy to clipboard

Posted by: dawnlong2000
Posted on: 2005-01-11 21:47

i've spent many days on studying the source codes of both struts and spring for the sake of my project. i prefer to spring.i felt the same as all of you,including Rod Johnson. in fact,we don't need so many as struts provided; i did my own design in my project.1)map the path to action as struts/spring did,but simplier;2) validate the input data on the client side by javascript to simplify error handling(don't need to redisplay on error);3)transform request data to java beans by means of introspection/spring's data binding;4) don't need tags--it's more understandable and convenient not to use tags.
it seems to me that in spring's configuration file,we can't make more than one view resovlers? i mean -- InternalResoureViewResolver and ResourceBundleViewResolver are not both used in the file,becaues we can't specify which to resolve the view names?

10.Re:Struts VS Spring Web [Re: tier3]	Copy to clipboard
Posted by: floater Posted on: 2005-01-11 23:04 that's correct, we can't use both resolvers in a single xml file. However, there is a view.properties that we can play with.