Структура папки веб-додатків Java

Як початківець J2EE, я нещодавно почав розробляти власний проект з нуля, використовуючи Core of J2EE: Servlets & Jsps.

Я не міг оцінити, чи правильна моя папка проекту. Ось моя структура папки проекту.

Перш ніж задавати питання, я визнаю, що я не зміг відповісти або не виправдати, якщо хтось запитує мене, чому такий тип структури папок. Питання: чи це хороший знак, щоб викласти jsps поза web-inf. Якщо ні, то чому так? Якщо так, чому?

Чи є стандартна угода про структуру папок для веб-програми J2EE, я знаю, що Maven створив деякі стандарти, але все ж ми можемо налаштувати відповідно до вимог, на які я вірю.

Я трохи погуглився і знайшов дві посилання 1 2

де відповіді знаходяться не на одній сторінці, з якої я не зміг зробити жодного висновку.

Які моменти слід враховувати, викладаючи структуру папок для веб-програми J2EE, головне, куди повинен входити Jsps, статичний вміст і чому?

Стандартна структура для файлу WAR:

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

Maven генерує це для вас, використовуючи src / main / java, ресурси, webapp та ваші залежності (розміщуючи їх у / lib) у плагіні maven-webapp , але це реалізація. Важливо усвідомити, що все, що ви вводите в WEB-INF, не є доступним зовні , тоді як все в кореневому каталозі ВІЙНИ є загальнодоступним.

Як правило, ви не хочете багато вкладати в корінь, оскільки хочете, щоб ваша програма обробляла весь доступ за допомогою сервлетів та фільтрів, визначених у web.xml. Поширене бачити в корені index.html (або .jsp), який перенаправляє сервлет, наприклад, дію Struts .

Типові MVC-реалізації, такі як Stripes або Struts, рекомендують забороняти користувачу звертатися безпосередньо до JSP, вважаючи за краще, щоб JSP були лише для перегляду. Вони рекомендують створити контролери, які пересилають JSP після обробки запиту, і JSP просто надають результат. Наприклад, надіславши форму для /loginзапуску дії, яка обробляє запит на вхід, створює сеанс користувача та пересилає користувача до режиму входу на головну сторінку JSP.

Звичайна відповідь "що це правильний шлях?" або "це правильний шлях?" це ..... це залежить .

Все, що я можу зробити, - це сказати вам плюси і мінуси конкретних ідей. Далі 100% моя думка. Я не знаю жодних конкретних вимог чи правил. Я впевнений, що хтось не погодиться зі мною.

Програми JSP

Давайте попрацюємо над тим, додавати JSP в WEB-INF чи ні.

Плюси розміщення JSP в WEB-INF:

• Ви керуєте тим, як виконуються програми JSP. Якщо ви хочете, щоб параметр JSP був параметризований і повторно використаний (що все-таки дуже важко з JSP), ви можете помістити їх у WEB-INF і використовувати сервлет або контролер дії Struts або інший передній контролер для попередньої обробки а потім передавати управління JSP, передаючи в потрібному контексті середовища (наприклад, атрибути запиту, будь-які перевірки безпеки, санація параметрів тощо)
• Ви можете програмно або навіть на рівні брандмауера або рівня IDS блокувати HTTP-запити до * .jsp, щоб зменшити ймовірність того, що хтось завантажить JSP у веб-корінь і потім зможе виконати код як веб-сервер. Їм доведеться переписати існуючий JSP. Не величезний приріст безпеки, але це робить компроміс трохи складніше.
• Застосовує хороші звички, такі як MVC, передній контролер, фільтри сервлетів, інжектор залежностей тощо, на відміну від великого жахливого JSP, який виконує всю роботу сам і важко читати / підтримувати.

Мінуси розміщення JSP в WEB-INF:

• Ви не можете отримати доступ до сторінки безпосередньо, навіть якщо це проста окрема сторінка, яка не потребує попередньої обробки. Це тому, що файли під / WEB-INF контейнером сервлетів не передаються.

Статичні файли

З точки зору чисто статичних файлів, таких як HTML, зображення, таблиця стилів, javascript тощо, покладіть їх під веб-корінь (my_app у вашому випадку), але НЕ / WEB-INF (тому що це недоступно).

Загальний макет

Що стосується загальної верстки каталогу, вона дещо залежить від вашого процесу збирання. Мені подобається зберігати все під "src" або "source", оскільки це дає зрозуміти, які файли створюються шляхом побудови та які є чистими вихідними файлами. mainдозволяє вам відокремити тестовий код, як класи Джуніт, від основного вихідного коду, що також добре. Але якщо у вас немає одиничних тестів (о, ні!), То це безглузда відмінність.

З іншого боку, якщо ви взагалі не маніпулюєте веб-корінцем під час збирання (наприклад, якщо це всі JSP та статичні файли), то, можливо, ви тримаєте його на найвищому рівні, як-от /webrootабо /deployкопіюєте файли в міру необхідності, наприклад, файли .class або .jar. Це звичка людини (особливо розробників) надмірно організовуватись. Хорошим знаком переорганізації є наявність великої кількості папок із лише однією підпапкою.

Що ви показали

Ви вказали, що дотримуєтесь конвенції, встановленої maven, тому якщо ви вже використовуєте maven, просто дотримуйтесь цього макета. З описаним вами макетом абсолютно нічого поганого.

Ну, ваш src / main / webapp напевно нагадує мені проект Maven. Що добре.

Для my_app / jsps я не впевнений. Зазвичай розробники залишають свій jsp в папці webapp або, якщо ви хочете трохи зробити URL-відображення, у каталозі webapp / jsp.

!Увага! : Ніколи не слід ставити файл jsp в web-inf. Ваш WEB-INF повинен містити лише файли xml для налаштування вашого веб-сайту. Пам'ятайте, що ваш jsp - це веб-сторінка або частина веб-сторінки.

Ви можете використовувати назву папок, як шаблон, частковий ... все, що вам добре. Для незнайомця його слід легко знайти. Просто розділіть різні типи вмісту, такі як повні сторінки, шаблони, часткові перегляди ...

Я згоден з Брісом . Я теж початківець в J2EE, але думаю, що на початку краще працювати легко і чітко.

Коренева папка - WEBAPP, і ви повинні змусити вашу веб-структуру думати, що більшість сторінок знайдуть там. Якщо ні, то, коли сторінки спілкуються між ними, напевно, ви не можете керувати файловими стосунками без помилок.

Насправді програма WAR може бути побудована без WEB-INF/web.xml . Можна зробити WAR-додаток із лише класами Java всередині.

Джерело: Елементи дескриптора розгортання web.xml

З анотаціями Java EE стандартний дескриптор розгортання web.xml необов’язковий. Відповідно до специфікації servlet 3.0 за адресою http://jcp.org/en/jsr/detail?id=315 , анотації можна визначити на певних веб-компонентах, таких як сервлети, фільтри, слухачі та обробники тегів.

Тож сьогодні можливо побудувати ВІЙНА, ніж схоже на JAR .war розширеннями :)

Відповідаючи на ваше запитання, структура ВОЙНА залежить від ваших вимог.

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