Ordnerstruktur der Java-Webanwendung

Als Anfänger von J2EE habe ich kürzlich damit begonnen, mein eigenes Projekt von Grund auf mit dem Kern von J2EE zu entwickeln: Servlets & Jsps.

Ich konnte nicht beurteilen, ob meine Projektordnerstruktur richtig ist oder nicht. Hier ist meine Projektordnerstruktur.

Bevor ich eine Frage stelle, gebe ich zu, dass ich weder antworten noch rechtfertigen konnte, wenn mich jemand fragt, warum diese Art von Ordnerstruktur vorliegt. Die Frage: Ist es ein gutes Zeichen, meine JSPs außerhalb von Web-Inf zu platzieren. Wenn nicht, warum ist das so? Wenn ja warum

Gibt es eine Standard-Ordnerstrukturkonvention für eine J2EE-Webanwendung, ich weiß, dass Maven einige Standards eingeführt hat, aber wir können sie trotzdem gemäß den Anforderungen anpassen, die ich glaube.

Ich habe ein bisschen gegoogelt und die beiden Referenzen gefunden 1 2

wo in den antworten nicht auf der gleichen seite, woraus ich keinen schluss ziehen konnte.

Was sind die Punkte, die beim Erstellen der Ordnerstruktur für eine J2EE-Webanwendung beachtet werden müssen, insbesondere, wo die JSPs abgelegt werden sollen und warum?

Die Standardstruktur für eine WAR-Datei lautet:

/META-INF
   Standard jar stuff like manifest.xml
/WEB-INF
  web.xml
  /classes
    /com...etc.
  /lib

Maven generiert dies für Sie mit Ihrer src / main / java, Ihren Ressourcen, Ihrer Web-App und Ihren Abhängigkeiten (die Sie in / lib ablegen ) im maven-webapp-Plugin , aber das ist die Implementierung. Es ist wichtig zu wissen, dass alles, was Sie in WEB-INF eingeben, nicht von außen zugänglich ist , wohingegen alles im Stammverzeichnis der WAR öffentlich ist.

Im Allgemeinen möchten Sie nicht viel in das Stammverzeichnis schreiben, da Ihre Anwendung den gesamten Zugriff mithilfe der in web.xml definierten Servlets und Filter verarbeiten soll. In der Regel wird im Stammverzeichnis eine index.html (oder .jsp) angezeigt, die zu einem Servlet umleitet, z. B. eine Struts- Aktion.

Typische MVC-Implementierungen wie Stripes oder Struts empfehlen, nicht direkt auf JSPs zuzugreifen. JSPs sollten nur angezeigt werden. Sie empfehlen, Controller zu erstellen, die nach der Verarbeitung der Anforderung an JSPs weiterleiten, und die JSPs rendern lediglich das Ergebnis. Wenn Sie beispielsweise ein Formular an senden, /loginwird eine Aktion ausgeführt, die die Anmeldeanforderung verarbeitet, die Sitzung des Benutzers erstellt und den Benutzer an die angemeldete Ansicht der Homepage-JSP weiterleitet.

Die übliche Antwort auf "Was ist der richtige Weg?" oder "ist das der richtige weg?" ist ..... es kommt darauf an .

Ich kann Ihnen nur die Vor- und Nachteile bestimmter Ideen erklären. Was folgt ist zu 100% meine Meinung. Ich kenne keine spezifischen Anforderungen oder Regeln. Ich bin sicher, jemand wird mit mir nicht einverstanden sein.

JSP's

Lassen Sie uns darüber nachdenken, ob JSPs in WEB-INF eingefügt werden sollen oder nicht.

Vorteile von JSPs in WEB-INF:

• Sie steuern, wie die JSPs ausgeführt werden. Wenn eine JSP parametrisiert und wiederverwendbar sein soll (was mit einer JSP ohnehin sehr schwierig ist), können Sie sie in WEB-INF einfügen und ein Servlet oder einen Struts-Action-Controller oder einen anderen Front-Controller für die Vorverarbeitung verwenden und dann die Steuerung an die JSP übergeben, wobei der richtige Umgebungskontext (wie Anforderungsattribute, etwaige Sicherheitsüberprüfungen, Parameterbereinigung usw.) übergeben wird.
• Sie können programmgesteuert oder sogar auf Firewall- oder IDS-Ebene HTTP-Anforderungen an * .jsp blockieren, um die Wahrscheinlichkeit zu verringern, dass jemand eine JSP in das Webstammverzeichnis hochlädt und dann Code als Webserver ausführen kann. Sie müssten eine vorhandene JSP überschreiben. Dies ist kein großer Sicherheitsgewinn, macht jedoch Kompromisse etwas schwieriger.
• Erzwingt gute Gewohnheiten wie MVC, Front-Controller, Servlet-Filter, Abhängigkeitsinjektion usw. im Gegensatz zu einer großen monströsen JSP, die die ganze Arbeit selbst erledigt und schwer zu lesen / zu warten ist.

Nachteile von JSPs in WEB-INF:

• Sie können nicht direkt auf die Seite zugreifen, auch wenn es sich um eine einfache eigenständige Seite handelt, für die keine Vorabverarbeitung erforderlich ist. Dies liegt daran, dass Dateien unter / WEB-INF nicht von einem Servlet-Container bedient werden können.

Statische Dateien

In Bezug auf rein statische Dateien wie HTML, Bild, Stylesheet, Javascript usw. legen Sie diese unter das Webstammverzeichnis (in Ihrem Fall my_app), aber NICHT / WEB-INF (da nicht darauf zugegriffen werden kann).

Gesamtlayout

Das gesamte Verzeichnislayout hängt etwas von Ihrem Erstellungsprozess ab. Ich mag es, alles unter "src" oder "source" zu speichern, weil es klar macht, welche Dateien beim Erstellen erzeugt werden und welche reine Quelldateien sind. mainErmöglicht es Ihnen, Testcode wie Junit-Klassen von Ihrem Hauptquellcode zu trennen, was ebenfalls gut ist. Aber wenn Sie keine Unit-Tests haben (oh nein!), Dann ist es eine bedeutungslose Unterscheidung.

Auf der anderen Seite, wenn Sie manipulieren nicht den Web - Root überhaupt während bauen (wie wenn sie alle JSP und statische Dateien sind), dann vielleicht Sie es auf der obersten Ebene zu halten, wie /webrootoder /deployund Kopieren von Dateien in je nach Bedarf, wie zum Beispiel Klassen- oder JAR-Dateien. Es ist eine Angewohnheit von Menschen (insbesondere Entwicklern), sich zu überorganisieren. Ein gutes Zeichen für eine Überorganisation sind viele Ordner mit nur einem Unterordner.

Was du gezeigt hast

Sie haben angegeben, dass Sie eine von maven festgelegte Konvention befolgen. Wenn Sie also bereits maven verwenden, bleiben Sie einfach bei diesem Layout. An dem von Ihnen beschriebenen Layout ist absolut nichts auszusetzen.

Nun, Ihre src / main / webapp erinnert mich sicherlich an ein Maven-Projekt. Was gut ist.

Für die my_app / jsps bin ich mir allerdings nicht sicher. Entwickler belassen ihre jsp normalerweise im Ordner "webapp" oder, wenn Sie ein wenig URL-Zuordnung vornehmen möchten, in einem Verzeichnis "webapp / jsp".

!Warnung! : Sie sollten niemals eine JSP-Datei in web-inf einfügen. Ihr WEB-INF sollte nur XML-Dateien enthalten, um Ihre Website zu konfigurieren. Denken Sie daran, dass Ihr jsp eine Webseite oder ein Teil einer Webseite ist.

Sie können Ordnernamen wie Vorlage, teilweise ... verwenden, was auch immer für Sie in Ordnung ist. Es sollte für einen Fremden leicht zu finden sein. Trennen Sie einfach verschiedene Arten von Inhalten wie Vollseiten, Vorlagen, Teilansichten ...

Ich stimme Brice zu . Ich bin auch Anfänger in J2EE, aber ich denke, dass es am Anfang besser ist, einfach und klar zu arbeiten.

Der Stammordner ist WEBAPP, und Sie sollten Ihre Webstruktur so einrichten, dass die meisten Seiten dort gespeichert werden. Wenn nicht, können Sie die Dateibeziehungen bei der Kommunikation zwischen den Seiten möglicherweise nicht fehlerfrei verwalten.

Wirklich kann WAR-Anwendung ohne konstruiert werden WEB-INF/web.xml. Es ist möglich, WAR-Anwendungen nur mit Java-Klassen zu erstellen.

Quelle: Ein web.xml-Deployment-Deskriptor-Element

Bei Java EE-Annotationen ist der Standard-Implementierungsdeskriptor web.xml optional. Gemäß der Servlet 3.0-Spezifikation unter http://jcp.org/en/jsr/detail?id=315 können für bestimmte Webkomponenten wie Servlets, Filter, Listener und Tag-Handler Anmerkungen definiert werden.

Heutzutage ist es also möglich, WAR zu erstellen, das wie JAR mit .warErweiterungen aussieht :)

Die WAR-Struktur hängt von Ihren Anforderungen ab.

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)