Struts1 erfordert, dass Aktionsklassen eine abstrakte Basisklasse erben. Ein häufiges Problem bei Struts1 ist die Programmierung mit abstrakten Klassen anstelle von Schnittstellen.
• Die Struts 2 Action-Klasse kann eine Action-Schnittstelle oder andere Schnittstellen implementieren und so optionale und angepasste Dienste ermöglichen. Struts2 bietet eine ActionSupport-Basisklasse zur Implementierung häufig verwendeter Schnittstellen. Die Action-Schnittstelle ist nicht erforderlich. Jedes POJO-Objekt mit der Ausführungskennung kann als Action-Objekt von Struts2 verwendet werden.
Thread-Modus:
• Struts1 Action ist ein Singleton-Modus und muss Thread-sicher sein, da nur eine Instanz von Action alle Anfragen verarbeitet. Die Singleton-Strategie schränkt die Möglichkeiten von Struts1 Action ein, und bei der Entwicklung ist besondere Vorsicht geboten. Aktionsressourcen müssen threadsicher oder synchronisiert sein.
• Das Struts2 Action-Objekt generiert eine Instanz für jede Anfrage, sodass es keine Thread-Sicherheitsprobleme gibt. (Tatsächlich generiert der Servlet-Container pro Anfrage viele verwerfbare Objekte und verursacht keine Leistungs- und LJ-Recyclingprobleme.)
Servlet-Abhängigkeiten:
• Struts1-Aktion basiert auf der Servlet-API, da HttpServletRequest und HttpServletResponse an die Ausführungsmethode übergeben werden, wenn eine Aktion aufgerufen wird.
• Die Aktion von Struts 2 ist nicht vom Container abhängig, sodass die Aktion unabhängig vom Container getestet werden kann. Struts2 Action kann bei Bedarf weiterhin auf die ursprüngliche Anfrage und Antwort zugreifen. Andere Elemente verringern oder beseitigen jedoch die Notwendigkeit, direkt auf HttpServetRequest und HttpServletResponse zuzugreifen.
Testbarkeit:
• Ein Hauptproblem beim Testen von Struts 1-Aktionen besteht darin, dass die Ausführungsmethode die Servlet-API verfügbar macht (wodurch das Testen vom Container abhängig wird). Eine Erweiterung eines Drittanbieters – Struts TestCase – stellt eine Reihe von Struts1-Mock-Objekten (zum Testen) bereit.
Struts 2 Action kann durch Initialisieren, Festlegen von Eigenschaften und Aufrufen von Methoden getestet werden. Die Unterstützung durch „Abhängigkeitsinjektion“ erleichtert auch das Testen.
Eingabe erfassen:
• Struts1 verwendet ActionForm-Objekte, um Eingaben zu erfassen. Alle ActionForms müssen eine Basisklasse erben. Da andere JavaBeans nicht als ActionForms verwendet werden können, erstellen Entwickler häufig redundante Klassen, um Eingaben zu erfassen. Dynamische Beans (DynaBeans) können als Alternative zum Erstellen herkömmlicher ActionForms verwendet werden. Entwickler müssen jedoch möglicherweise vorhandene JavaBeans neu beschreiben (erstellen), was immer noch zu redundanten Javabeans führt.
• Struts 2 verwendet Aktionseigenschaften direkt als Eingabeeigenschaften, sodass kein zweites Eingabeobjekt erforderlich ist. Eingabeeigenschaften können umfangreiche Objekttypen mit eigenen (Unter-)Eigenschaften sein. Auf Aktionseigenschaften kann über Taglibs auf der Webseite zugegriffen werden. Struts2 unterstützt auch den ActionForm-Modus. Als Eingabe-/Ausgabeobjekte können umfangreiche Objekttypen, einschließlich Geschäftsobjekten, verwendet werden. Diese ModelDriven-Funktion vereinfacht den Verweis von Taglib auf POJO-Eingabeobjekte.
Ausdruckssprache:
• Struts1 integriert JSTL und verwendet daher JSTL EL. Dieser EL verfügt über eine grundlegende Durchquerung von Objektgraphen, die Unterstützung für Sammlungen und indizierte Eigenschaften ist jedoch schwach.
• Struts2 kann JSTL verwenden, unterstützt aber auch eine leistungsfähigere und flexiblere Ausdruckssprache – „Object Graph Notation Language“ (OGNL).
Binden Sie den Wert an die Seite (Ansicht):
• Struts 1 verwendet Standard-JSP-Mechanismen, um Objekte für den Zugriff an Seiten zu binden.
Struts 2 verwendet die „ValueStack“-Technologie, um Taglib den Zugriff auf Werte zu ermöglichen, ohne Ihre Seite (Ansicht) an das Objekt zu binden. Die ValueStack-Strategie ermöglicht die Wiederverwendung von Seiten (Ansichten) durch eine Reihe von Eigenschaften mit demselben Namen, aber unterschiedlichen Typen.
Typkonvertierung:
• Struts 1 ActionForm-Eigenschaften sind normalerweise vom Typ String. Struts1 verwendet Commons-Beanutils zur Typkonvertierung. Ein Konverter pro Klasse, nicht pro Instanz konfigurierbar.
• Struts2 verwendet OGNL für die Typkonvertierung. Bietet Konverter für grundlegende und häufig verwendete Objekte.
überprüfen:
• Struts 1 unterstützt die manuelle Überprüfung in der Validierungsmethode von ActionForm oder die Überprüfung durch die Erweiterung von Commons Validator. Dieselbe Klasse kann unterschiedliche Verifizierungsinhalte haben, Unterobjekte können jedoch nicht verifiziert werden.
• Struts2 unterstützt die Verifizierung durch die Validierungsmethode und das XWork-Verifizierungsframework. Das XWork-Validierungsframework verwendet die für den Attributklassentyp definierte Validierung und Inhaltsvalidierung, um die Untereigenschaft der Kettenvalidierung zu unterstützen.
Kontrolle der Aktionsausführung:
• Struts1 unterstützt separate Anforderungsprozessoren (Lebenszyklus) für jedes Modul, aber alle Aktionen im Modul müssen denselben Lebenszyklus haben.
• Struts2 unterstützt die Erstellung unterschiedlicher Lebenszyklen für jede Aktion durch Interceptor Stacks. Stapel können je nach Bedarf mit verschiedenen Aktionen verwendet werden
Dieser Artikel stammt aus dem CSDN-Blog. Bitte geben Sie beim Nachdruck die Quelle an: http://blog.csdn.net/Ryan_lz/archive/2009/12/29/5101758.aspx