Struts1 nécessite que les classes Action héritent d'une classe de base abstraite. Un problème courant avec Struts1 est la programmation avec des classes abstraites au lieu d'interfaces.
• La classe Action de Struts 2 peut implémenter une interface Action ou d'autres interfaces, rendant possibles des services facultatifs et personnalisés. Struts2 fournit une classe de base ActionSupport pour implémenter les interfaces couramment utilisées. L'interface Action n'est pas requise. Tout objet POJO avec l'identifiant d'exécution peut être utilisé comme objet Action de Struts2.
Mode fil :
• Struts1 Action est un mode singleton et doit être thread-safe, car une seule instance d’Action gère toutes les requêtes. La stratégie singleton limite ce que Struts1 Action peut faire et un soin particulier doit être apporté lors du développement. Les ressources d’action doivent être thread-safe ou synchronisées.
• L'objet Struts2 Action génère une instance pour chaque requête, il n'y a donc aucun problème de sécurité des threads. (En fait, le conteneur de servlets génère de nombreux objets jetables par requête et ne provoque pas de problèmes de performances ni de recyclage LJ)
Dépendances des servlets :
• L'action Struts1 repose sur l'API Servlet car HttpServletRequest et HttpServletResponse sont transmis à la méthode d'exécution lorsqu'une action est appelée.
• L'action Struts 2 ne dépend pas du conteneur, ce qui permet de tester l'action indépendamment du conteneur. Struts2 Action peut toujours accéder à la demande et à la réponse d'origine si nécessaire. Cependant, d'autres éléments réduisent ou éliminent le besoin d'accéder directement à HttpServetRequest et HttpServletResponse.
Testabilité :
• Un problème majeur avec le test des actions Struts 1 est que la méthode d'exécution expose l'API du servlet (ce qui rend les tests dépendants du conteneur). Une extension tierce - Struts TestCase - fournit un ensemble d'objets fictifs Struts1 (pour les tests).
Struts 2 Action peut être testé en initialisant, en définissant des propriétés et en appelant des méthodes. La prise en charge de « l'injection de dépendances » facilite également les tests.
Capturer l'entrée :
• Struts1 utilise les objets ActionForm pour capturer les entrées. Tous les ActionForms doivent hériter d'une classe de base. Étant donné que les autres JavaBeans ne peuvent pas être utilisés comme ActionForms, les développeurs créent souvent des classes redondantes pour capturer les entrées. Les Dynamic Beans (DynaBeans) peuvent être utilisés comme alternative à la création d'ActionForms traditionnels. Cependant, les développeurs peuvent re-décrire (créer) des JavaBeans existants (ce qui entraîne toujours des javabeans redondants).
• Struts 2 utilise les propriétés d'action directement comme propriétés d'entrée, éliminant ainsi le besoin d'un deuxième objet d'entrée. Les propriétés d'entrée peuvent être des types d'objets riches avec leurs propres (sous-)propriétés. Les propriétés de l'action sont accessibles via les taglibs sur la page Web. Struts2 prend également en charge le mode ActionForm. Les types d'objets riches, y compris les objets métier, peuvent être utilisés comme objets d'entrée/sortie. Cette fonctionnalité ModelDriven simplifie la référence de taglib aux objets d'entrée POJO.
Langue d'expression :
• Struts1 intègre JSTL et utilise donc JSTL EL. Cet EL a une traversée de graphe d'objets de base, mais la prise en charge des collections et des propriétés indexées est faible.
• Struts2 peut utiliser JSTL, mais prend également en charge un langage d'expression plus puissant et plus flexible : "Object Graph Notation Language" (OGNL).
Liez la valeur à la page (vue) :
• Struts 1 utilise les mécanismes JSP standard pour lier les objets aux pages pour y accéder.
Struts 2 utilise la technologie "ValueStack" pour permettre à taglib d'accéder aux valeurs sans lier votre page (vue) à l'objet. La stratégie ValueStack permet de réutiliser des pages (vues) à travers une série de propriétés portant le même nom mais de types différents.
Conversion de types :
• Les propriétés ActionForm de Struts 1 sont généralement de type String. Struts1 utilise Commons-Beanutils pour la conversion de type. Un convertisseur par classe, non configurable par instance.
• Struts2 utilise OGNL pour la conversion de type. Fournit des convertisseurs pour les objets de base et couramment utilisés.
vérifier:
• Struts 1 prend en charge la vérification manuelle dans la méthode de validation d'ActionForm, ou la vérification via l'extension de Commons Validator. La même classe peut avoir des contenus de vérification différents, mais les sous-objets ne peuvent pas être vérifiés.
• Struts2 prend en charge la vérification via la méthode validate et le framework de vérification XWork. Le framework de validation XWork utilise la validation et la validation de contenu définies pour le type de classe d'attribut pour prendre en charge la sous-propriété de validation de chaîne.
Contrôle de l'exécution des actions :
• Struts1 prend en charge des processeurs de requêtes (cycle de vie) distincts pour chaque module, mais toutes les actions du module doivent partager le même cycle de vie.
• Struts2 prend en charge la création de cycles de vie différents pour chaque action via des piles d'intercepteurs. Les piles peuvent être utilisées avec différentes actions selon les besoins
Cet article provient du blog CSDN Veuillez indiquer la source lors de la réimpression : http://blog.csdn.net/Ryan_lz/archive/2009/12/29/5101758.aspx.