Java开发网 - Re:Struts VS Spring Web

Java开发网

您没有登录

» Java开发网 » Architecture & Framework » Spring Framework

打印话题 寄给朋友 订阅主题

作者

Re:Struts VS Spring Web [Re:tier3]

sunfmin

发贴: 41
积分: 10

于 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é.

话题树型展开

人气	标题	作者	字数	发贴时间
24491	Struts VS Spring Web	tier3	284	2004-09-15 19:52
22846	Re:Struts VS Spring Web	tier3	202	2004-09-15 19:54
23673	Re:Struts VS Spring Web	floater	2300	2004-09-16 01:27
22825	Re:Struts VS Spring Web	tier3	769	2004-09-16 09:17
22598	Re:Struts VS Spring Web	floater	207	2004-09-16 22:30
22420	Re:Struts VS Spring Web	bill1	28	2004-09-29 08:32
22937	Re:Struts VS Spring Web	sunfmin	4558	2004-12-24 16:24
22394	Re:Struts VS Spring Web	floater	121	2004-12-24 21:37
22599	Re:Struts VS Spring Web	dawnlong2000	856	2005-01-11 21:47
23040	Re:Struts VS Spring Web	floater	124	2005-01-11 23:04

已读帖子

新的帖子

被删除的帖子