Зачем использовать множество подпроектов и зависимостей над пакетами?

Ive в основном в моей карьере работала в небольших или средних проектах Java. Недавно я увидел огромный проект, состоящий из 30 проектов в eclipse. Я действительно не понимаю концепцию создания множества небольших проектов, а затем поддерживаю межпроектные зависимости. Когда мы предпочитаем это, просто организуя вещи в пакетах?

Я догадался о своей вещи (в основном использовал Ant). Я также читал о концепции модулей Mavens - я видел некоторые ссылки на сети, рекомендующие создание разных модулей для веб-страниц, dao и сервисов в родительском модуле. Действительно ли это обычная/лучшая практика?

С или без maven - действительно ли такое разделение облегчает жизнь? Разве не более компактно иметь все в одном проекте с четко определенной структурой пакетов для разных слоев?

Ответ 1

Обычно для разделения проектов на компоненты API, реализации, сети и т.д., когда это необходимо. Большие проекты - это просто: большие.

Есть преимущества для сохранения отдельных компонентов

Функция повторного использования (например, веб-уровень использует сервисный уровень
Пакет отдельных компонентов (например, отправка API клиенту)
Подкомпоненты версии; определить их зависимости от версии

Вы можете делать все то же самое с одним гигантским проектом, но сложнее определить, что происходит, и почему. Жизнь легче, когда четко обозначены эти демаркации.

Насколько это проще зависит от проекта, но когда вы имеете дело со сотнями тысяч строк кода, изредка миллионы людей, нарушая это, экономит огромные головные боли.

Ответ 2

Почему вы хотите создать отдельный модуль в maven? Чтобы помочь вам в развитии. Нет другой причины.

Существует несколько разных причин, по которым вам может понадобиться создать отдельный модуль:

Разделение проблем: да, вы можете сделать это с помощью пакетов, но если это в отдельном модуле, тогда его можно скомпилировать отдельно, и вы можете уменьшить количество путаницы [*] в своих пакетах.
Модули управляются разными командами с собственными циклами выпуска.
Более понятный код: если весь ваш код dao находится в одном модуле, а все ваши веб-страницы в другом, вы можете протестировать их отдельно.
Модуль может быть отдельным развертываемым объектом. У меня есть проект, в котором есть два веб-приложения, 5 партий и два других основных модуля (одно ядро для webapp и одно ядро для партий). Теперь я могу создавать и развертывать каждый модуль отдельно.
Модули публикуются и используются снаружи. Если это правда, тогда вы хотите, чтобы минимальный объем "другого" кода в этом модуле.

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

30 кажется чрезмерным. Но для этого могут быть веские причины. Это зависит от вас и вашего проекта, чтобы определить, что является правильным уровнем для количества модулей.

Лично я стараюсь не расколоться чрезмерно, если нет веских оснований для этого.

[*] Tangle: беспорядок, который описывает ссылки между пакетами. В пакете A используется B, в котором используется C, который использует как A, так и B. Что-то, что не помогает понять.

Ответ 3

Я думаю, что чрезмерная модуляция похожа на инженерную. Лучший способ, на мой взгляд, - начать с одного модуля/проекта и сохранить его до тех пор, пока не станет очевидным, чтобы все участвовали в том, что часть этого существующего модуля выиграет от того, чтобы быть извлеченным в его собственный модуль. Да, это означает дополнительную работу в этот момент, но для меня я предпочел бы выполнить эту работу, чем бесконечную битву с ненужной сложностью, с точки зрения моих построений и моей среды разработки, для преимуществ, которые никогда не реализуются.

К сожалению, в начале проектов, по-видимому, существует тенденция к модуляции до n-й степени, прежде чем будет записана даже одна строка кода.

Ответ 4

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