Java Practices: Struts seems mediocre

Nada contra Struts (nada… aham… heahuae), mas é q gosto de criar tópicos q gerem discuções legais… Bem, sobre o Struts, é isso oq se encontra no

Na íntegra:

The Struts front end framework was one of the first java web application tools to be published, and it enjoys wide popularity.

(Calling Struts an “application framework” is inaccurate. Struts assists the developer in building only the front end of an application. It does nothing for the model layer or the database layer.)

It can be argued with some force that Struts is a mediocre tool. Here are some reasons why.

No policies for translating request parameters into common java objects.

All java web applications need to translate raw request parameter values into common items such as Integer, Date, and BigDecimal. However, Struts provides absolutely no support for this task. It does not define reasonable default policies, nor does it encourage the user to define such policies in any way.

ActionForms are a massive parallel structure to the “real” model.

The ActionForm classes are not intended as the actual model. They are intended as a preliminary validation buffer between the raw HTTP request and the “real” model class. (For example, an ActionForm might validate that a request parameter can be parsed into an Integer, whereas the related model class might validate that the Integer is within the range 1…10.) ActionForms include only String and boolean items, and nothing else. Since ActionForms and model classes exist as a pair, this creates massive unnecessary parallelism.

This point is closely related to the first one. If centrally defined policies for translating request parameters into Integer, Date, BigDecimal, and so on, existed, then model objects could indeed be constructed out of request parameters more or less directly.

Furthermore, even though Struts requires that model objects be constructed out of related ActionForms, it gives no direct support to the programmer for performing this task.

Standard HTML forms are not used.

In Struts, forms usually depart widely from standard HTML, and are usually implemented with a specific set of custom tags. This is neither necessary nor desirable. It is not necessary since other tools have demonstrated that dynamically populated forms can simply reuse standard HTML forms as part of their implementation. It is not desirable since the page author cannot reuse their knowledge of standard HTML, but is instead forced to learn a new set of custom tags specific to Struts. This is unproductive.

Actions must be thread-safe.

Actions are always cached and reused by Struts. This is both a performance optimization and a constraint, since it requires Actions to be safe for use in a multi-threaded environment.

As a performance optimization, this policy is of dubious quality. The stack traces of a web container are large. If an Action is “just another object”, it is of very little benefit to cache and reuse it. On the other hand, designs in which an Action holds a reference to an expensive object (such as a database connection) are often inferior.

As a constraint, Joshua Bloch explains clearly in Effective Java that ensuring a class is usable in a multi-threaded environment is a non-trivial task. Forcing all Action implementations to be thread-safe seems an onerous requirement having doubtful benefit. For example, in a Struts Action, data shared between methods cannot be stored in a field ; rather, it must be passed as a parameter.

Struts is an unimpressive implementation of the Command pattern.

The execute method has four arguments, which must always be passed in, regardless of whether or not the argument is actually relevant to a particular action. In the Design Patterns book, the number of arguments to the execute method is exactly zero. There is a good reason for this, and it is illustrated by almost every design pattern in the Gang Of Four book : the central methods of any design are free of implementation details. Data needed by the implementation of an abstraction is almost always passed to a constructor. This keeps the abstractions clean, and places data specific to the implementation in a place where inheritance and polymorphism do not apply (the constructor).

In addition, Struts always requires a cast to be performed in an Action. Casts are something to be avoided unless absolutely necessary, since they lead to runtime errors.

The web4j tool was built out of strong dissatisfaction with the Struts front end framework.

ok, agora comparações com relação ao Webwork:

hehe, td bem, é uma tentativa minha de mostrar aos usuários novos em frameworks MVC, caminhos mais simples q o Struts…


é… concordo com quase tudo escrito ai… Modelo não é bem definido. Pq usar taglibs ao inves de html puro. etc

Mas, conhecer Struts hoje é extremamente importante, mesmo qeu não seja para desenvolver aplicações em cima dele.

  • Saiba Struts, vc vai precisar dele.
  • Se achar o WW melhor que ele, desenvolva novas aplicações em cima dele. Mas vc ainda vai precisar saber Struts.


Nenhum conhecimento é demais!!!
Os puristas morrem de fome :wink:

e vamo que vamo! .Net rules!!

[quote=“jujo”]Mas, conhecer Struts hoje é extremamente importante, mesmo qeu não seja para desenvolver aplicações em cima dele.

  • Saiba Struts, vc vai precisar dele.
  • Se achar o WW melhor que ele, desenvolva novas aplicações em cima dele. Mas vc ainda vai precisar saber Struts.


Nenhum conhecimento é demais!!!
Os puristas morrem de fome :wink:

concordo com tudo jujo… só postei pra fomentar :slight_smile:

e vamo que vamo! .Net rules!!


é foda!!!
O Struts hoje é meu ganha Pão!!! Ver alguem debochar disso é muito ruim!!! Sei que existem outros framework’s mais o struts é tao grande e tão completo!!!
Esse tipo de reportagem serve apenas para agente não se acomodar! Achar que sabe struts bem e chega! Temos realmente sempre que procurar evoluir ainda mais quando se trata de J2EE!!!
Mas olhando para traz hoje me lembro de quando era Programador Delphi e me achava na minha empresa!! Depois esnobei o delphi e fui mecher com Java!! Me lembro antes que quando era Monitor da Faculdade destruia o Pascal!! E o C++!! Hoje vejo que tudo que vai ficando para traz vai ficando ridiculo!!!
Temos realmente que evoluir!! O triste é que cada vez mais vejo que quando mais aprendo coisas novas mais eu vejo que não sei nada!!!

ahkahuka óh o Anderson ficando doido… eahhauhuae, mas é assim mesmo cara… sei como é… bem, eu tb uso Struts no projeto q to envolvido heheh, fazer oq né…