Struts1 requer classes Action para herdar uma classe base abstrata. Um problema comum com o Struts1 é programar com classes abstratas em vez de interfaces.
A classe Action do Struts 2 pode implementar uma interface Action ou outras interfaces, possibilitando serviços opcionais e customizados. Struts2 fornece uma classe base ActionSupport para implementar interfaces comumente usadas. A interface Action não é necessária. Qualquer objeto POJO com o identificador de execução pode ser usado como objeto Action do Struts2.
Modo de discussão:
• Struts1 Action é um modo singleton e deve ser thread-safe, porque apenas uma instância de Action lida com todas as solicitações. A estratégia singleton limita o que o Struts1 Action pode fazer e cuidados especiais devem ser tomados durante o desenvolvimento. Os recursos de ação devem ser thread-safe ou sincronizados.
• O objeto Action do Struts2 gera uma instância para cada solicitação, portanto não há problemas de segurança de thread. (Na verdade, o contêiner do servlet gera muitos objetos descartáveis por solicitação e não causa problemas de desempenho e reciclagem de LJ)
Dependências de servlets:
• Struts1 Action depende da API Servlet porque HttpServletRequest e HttpServletResponse são passados para o método execute quando uma Action é chamada.
• A ação do Struts 2 não depende do contêiner, permitindo que a ação seja testada independentemente do contêiner. O Struts2 Action ainda pode acessar a solicitação e a resposta originais, se necessário. No entanto, outros elementos reduzem ou eliminam a necessidade de acessar HttpServetRequest e HttpServletResponse diretamente.
Testabilidade:
Um grande problema com o teste de ações do Struts 1 é que o método execute expõe a API do servlet (que torna o teste dependente do contêiner). Uma extensão de terceiros - Struts TestCase - fornece um conjunto de objetos simulados do Struts1 (para teste).
O Struts 2 Action pode ser testado inicializando, definindo propriedades e chamando métodos. O suporte à "injeção de dependência" também facilita o teste.
Entrada de captura:
• Struts1 usa objetos ActionForm para capturar entrada. Todos os ActionForms devem herdar uma classe base. Como outros JavaBeans não podem ser usados como ActionForms, os desenvolvedores geralmente criam classes redundantes para capturar entradas. Dynamic Beans (DynaBeans) podem ser usados como uma alternativa à criação de ActionForms tradicionais. No entanto, os desenvolvedores podem estar redescrevendo (criando) JavaBeans existentes (ainda resultando em javabeans redundantes).
• Struts 2 usa propriedades de ação diretamente como propriedades de entrada, eliminando a necessidade de um segundo objeto de entrada. As propriedades de entrada podem ser tipos de objetos ricos com suas próprias (sub) propriedades. As propriedades da ação podem ser acessadas por meio de taglibs na página da web. Struts2 também suporta o modo ActionForm. Tipos de objetos ricos, incluindo objetos de negócios, podem ser usados como objetos de entrada/saída. Este recurso ModelDriven simplifica a referência do taglib aos objetos de entrada POJO.
Linguagem de expressão:
• Struts1 integra JSTL e, portanto, usa JSTL EL. Este EL possui travessia básica de gráfico de objetos, mas o suporte para coleções e propriedades indexadas é fraco.
• Struts2 pode usar JSTL, mas também suporta uma linguagem de expressão mais poderosa e flexível - "Object Graph Notation Language" (OGNL).
Vincule o valor à página (visualização):
• Struts 1 usa mecanismos JSP padrão para vincular objetos a páginas para acesso.
O Struts 2 usa a tecnologia "ValueStack" para permitir que o taglib acesse valores sem vincular sua página (visualização) ao objeto. A estratégia ValueStack permite a reutilização de páginas (views) através de uma série de propriedades com o mesmo nome, mas de tipos diferentes.
Conversão de tipo:
• Struts 1 As propriedades ActionForm são geralmente do tipo String. Struts1 usa Commons-Beanutils para conversão de tipo. Um conversor por classe, não configurável por instância.
• Struts2 usa OGNL para conversão de tipo. Fornece conversores para objetos básicos e comumente usados.
verificar:
• Struts 1 suporta verificação manual no método de validação do ActionForm ou verificação por meio da extensão do Commons Validator. A mesma classe pode ter conteúdos de verificação diferentes, mas os subobjetos não podem ser verificados.
• Struts2 suporta verificação por meio do método de validação e da estrutura de verificação XWork. A estrutura de validação XWork usa a validação e validação de conteúdo definidas para o tipo de classe de atributo para suportar a subpropriedade de validação em cadeia.
Controle de execução de ações:
• Struts1 suporta processadores de solicitação separados (ciclo de vida) para cada módulo, mas todas as ações no módulo devem compartilhar o mesmo ciclo de vida.
• Struts2 suporta a criação de diferentes ciclos de vida para cada ação por meio de Interceptor Stacks. As pilhas podem ser usadas com diferentes ações conforme necessário
Este artigo vem do blog CSDN. Indique a fonte ao reimprimir: http://blog.csdn.net/Ryan_lz/archive/2009/12/29/5101758.aspx.