Структура пакета для Java-проекта?

116

Как лучше всего настроить структуры пакетов в веб-приложении Java?

Как бы вы настроили свой src, код модульного теста и т. Д.?

java packages

— Mawaldne
источник

95

Вы можете следовать стандартному макету проекта maven . Вам не обязательно использовать maven, но это упростит переход в будущем (при необходимости). Кроме того, другие разработчики будут привыкать к этой схеме, поскольку многие проекты с открытым исходным кодом построены таким образом,

— johnstok
источник

2

Я также рекомендую использовать макет Maven, если у вас есть выбор. Это хорошо продуманная структура, проверенная на практике и знакомая многим разработчикам.

— Дов Вассерман

15

Вы можете использовать этот oneliner для создания макета каталога: mkdir -p src / {main / {java, resources, filters, assembly, config, webapp}, test / {java, resources, filters}, site}

— Дэниел Хеппер,

1

Стандартный макет проекта Maven уродлив ...: /

— Юша Алеайуб

2

@YoushaAleayoub, тебе не обязательно выходить за него замуж

— Ашвин Шарма

59

Вы можете проверить несколько существующих ресурсов:

Как бы то ни было, мои личные рекомендации, которые я обычно использую, следующие:

Начните с обратного домена, например "com.mycompany".
Используйте название продукта, например "myproduct". В некоторых случаях у меня есть общие пакеты, которые не относятся к конкретному продукту. В конечном итоге они будут разделены на категории в соответствии с функциональностью этих общих классов, например «io», «util», «ui» и т. Д.
После этого он приобретает более свободный вид. Обычно я группирую по проекту, функциональности, развертыванию и т. Д. Например, у меня могут быть «проект1», «проект2», «пользовательский интерфейс», «клиент» и т. Д.

Еще пара моментов:

В проектах, над которыми я работал, довольно часто случается, что имена пакетов вытекают из проектной документации. Обычно продукты уже разделены на области функциональности или назначения.
Не переживайте из-за того, что сразу добавите общие функции в пакеты более высокого уровня. Подождите, пока возникнет потребность в проектах, продуктах и т. Д., А затем выполните рефакторинг.
Следите за зависимостями между пакетами. Не все они плохие, но это может означать тесную связь между отдельными единицами. Есть инструменты, которые помогут вам это отслеживать.

— Lycono
источник

2

В случае обратного домена ("com.mycompany") пакет "com" обычно пуст, за исключением подпакета "mycompany"?

— Alex Parker

45

Я бы предложил создавать структуру вашего пакета по функциям, а не по уровню реализации. Хорошая запись об этом - практика Java: пакет за функцией, а не слой

— аналитик данных
источник

2

Спасибо. Это то, что я искал, чтобы передать свои мысли команде

— Пранали

8

А если вы хотите переключить базы данных? Достаточно посмотреть 30 разных пакетов. Перейти с SFTP на веб-сервисы? Опять же нужно только посмотреть в 30 разных местах. Определенно не фанат.

— SamuelKDavis

1

другой пример, когда упаковка по слоям имеет преимущества: если вы сериализуете классы в JSON (например, с помощью gson), если эти классы запутаны (например, Proguard) (де) сериализация не удастся; вам нужно настроить Proguard так, чтобы такие классы не касались - проще всего указать один пакет со всеми из них

— jmuet

6

Обычно мне нравится следующее:

bin (двоичные файлы)
doc (Документы)
inf (Информация)
lib (библиотеки)
res (Ресурсы)
src (Источник)
tst (Тест)

Это можно считать нетрадиционным, но я считаю, что это очень хороший способ организовать вещи.

«Их можно считать нетрадиционными». Они на самом деле нетрадиционные и, кстати, плохие ...

— mahieddine

2

@mahieddine Почему ты считаешь их плохими?

— Томас Йоханнесмейер

Ну, это не я сказал это, но вот некоторые из моих мыслей: ваши тестовые классы - это исходный код, поэтому каталог "tst" (большинство людей не сокращает test btw) должен быть подкаталогом src (например, " src становится src / main, а tst становится src / test). Также "inf", похоже, включает контент, который может быть в "doc".

— Нико Вавжиняк,

6

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

— Радж
источник

3

Как у меня обычно иерархия папок -

название проекта
- src
- бункер
- тесты
- ЛИЭС
- документы

— пдева
источник

1

Еще один способ - разделить API, службы и сущности на разные пакеты.

— Дипак Патанкар
источник