Zwykła odpowiedź na „jaka jest właściwa droga?” lub „czy to właściwa droga?” jest ... to zależy .
Wszystko, co mogę zrobić, to przedstawić zalety i wady konkretnych pomysłów. Poniżej 100% mojej opinii. Nie znam żadnych konkretnych wymagań ani zasad. Jestem pewien, że ktoś się ze mną nie zgodzi.
JSP
Zastanówmy się, czy umieścić JSP w WEB-INF, czy nie.
Zalety umieszczania stron JSP w WEB-INF:
- Kontrolujesz sposób wykonywania stron JSP. Jeśli chcesz sparametryzować JSP i nadawać się do ponownego użycia (co i tak jest naprawdę trudne z JSP), możesz umieścić je w WEB-INF i użyć serwletu lub kontrolera akcji Struts lub innego kontrolera frontowego do wstępnego przetwarzania a następnie przekazać kontrolę do strony JSP, przekazując w odpowiednim kontekście środowiska (np. atrybuty żądania, wszelkie kontrole bezpieczeństwa, parametry sanitarne itp.)
- Możesz programowo lub nawet na poziomie zapory ogniowej lub poziomu IDS blokować żądania HTTP do * .jsp, aby zmniejszyć prawdopodobieństwo, że ktoś załaduje plik JSP do katalogu głównego, a następnie będzie mógł wykonać kod jako serwer WWW. Musieliby nadpisać istniejący plik JSP. Nie jest to duży zysk bezpieczeństwa, ale kompromis jest nieco trudniejszy.
- Wymusza dobre nawyki, takie jak MVC, kontroler przedni, filtry serwletów, wstrzykiwanie zależności itp. W przeciwieństwie do dużego, potwornego JSP, który wykonuje całą pracę sam i jest trudny do odczytania / utrzymania.
Wady umieszczania stron JSP w WEB-INF:
- Nie możesz uzyskać dostępu do strony bezpośrednio, nawet jeśli jest to prosta samodzielna strona, która nie wymaga wstępnego przetwarzania. Wynika to z faktu, że pliki w katalogu / WEB-INF nie są obsługiwane przez kontener serwletu.
Pliki statyczne
Jeśli chodzi o czysto statyczne pliki, takie jak HTML, obraz, arkusz stylów, javascript itp., Umieść je w katalogu głównym (my_app w twoim przypadku), ale NIE / WEB-INF (ponieważ nie jest dostępny).
Ogólny układ
Jeśli chodzi o ogólny układ katalogu, zależy to nieco od procesu kompilacji. Lubię przechowywać wszystko pod „src” lub „source”, ponieważ wyjaśnia, jakie pliki są generowane przez kompilację, a które są czystymi plikami źródłowymi. mainpozwala oddzielić kod testowy, taki jak klasy junit, od głównego kodu źródłowego, co również jest dobre. Ale jeśli nie masz żadnych testów jednostkowych (o nie!), To bez znaczenia jest rozróżnienie.
Z drugiej strony, jeśli nie manipulujesz katalogiem głównym podczas kompilacji (np. Jeśli są to tylko pliki JSP i pliki statyczne), być może utrzymujesz go na najwyższym poziomie, np. /webrootLub /deploykopiujesz pliki w razie potrzeby, takie jak Pliki .class lub .jar. Jest nawykiem ludzi (szczególnie deweloperów) do nadmiernej organizacji. Dobrym znakiem nadmiernej organizacji jest posiadanie dużej liczby folderów z tylko jednym podfolderem.
Co pokazałeś
Wskazałeś, że przestrzegasz konwencji ustalonej przez maven, więc jeśli już korzystasz z maven, po prostu trzymaj się tego układu. Nie ma absolutnie nic złego w opisanym układzie.
