Обычный ответ на вопрос "что такое правильный путь?" или "это правильный путь?" это ..... это зависит .
Все, что я могу сделать, это рассказать вам о плюсах и минусах конкретных идей. То, что следует, на 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позволяет отделить тестовый код, например классы junit, от основного исходного кода, что тоже хорошо. Но если у вас нет юнит-тестов (о нет!), То это бессмысленное различие.
С другой стороны, если вы вообще не управляете веб-корнем во время сборки (например, если это все JSP и статические файлы), то, возможно, вы сохраните его на верхнем уровне, например, /webrootили /deployскопируете файлы по мере необходимости, такие как .class или .jar файлы. Это привычка людей (особенно разработчиков) к чрезмерной организации. Хорошим признаком чрезмерной организации является наличие множества папок только с одной подпапкой.
Что вы показали
Вы указали, что соблюдаете соглашение, установленное maven, поэтому, если вы уже используете maven, просто придерживайтесь этого макета. В макете, который вы описали, нет ничего плохого.
