Когда создавать несколько проектов в Eclipse?

Question

Я часто опасаюсь создавать несколько проектов в Eclipse. Давайте рассмотрим сценарий:

• Существует основной проект J2EE, в котором есть вся бизнес-логика, графический интерфейс визуализации и т. Д.
• Затем есть еще один проект поддержки, который в основном имеет только конфигурационные материалы, связанные с Hibernate POJO и Hibernate *

Это означает, что банку проекта Hibernate нужно будет поместить в основной проект, чтобы протестировать его каждый раз, когда происходят изменения.

Какие недостатки?

• Наименьшее изменение в классе, вам нужно заново собрать банку и перенести на сервер
• Вы не можете напрямую только передавать файлы классов, вам нужно снова собрать полный jar
• В режиме удаленной отладки изменения не будут заменять файлы классов из проекта Hibernate в горячем режиме, из-за чего все время приходится переносить jar и перезагружать сервер

В чем преимущества?

• Если бы мне пришлось разделить свой проект J2EE на 2 проекта, чтобы разделить задачу завтра, я могу напрямую скопировать часть БД, т. Е. Банку Hibernate и начать использовать разделенные проекты

Итак, теперь мой вопрос:

• Есть ли руководящие указания относительно того, когда создавать новый проект вместо нового пакета?
• В подобных случаях было бы неплохо объединить оба проекта в один, чтобы устранить 3 недостатка и получить одно преимущество?
• Что такое отраслевой стандарт? Лучшая практика?

Answer 1

Чем больше вы можете отделить свои проекты, тем лучше.

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

Answer 2

В вашем случае, если у вас есть разные слои, можно поместить слои в разные проекты.Это дает дополнительную мотивацию для разделения слоев, общения через интерфейсы и предотвращения циркулярных зависимостей между слоями (проекты не могут зависеть друг от друга!)

Я часто представляю один специализированный проект, который содержит все библиотеки и ресурсыдля всего приложения.Может быть, другой, который используется только для сборки и развертывания приложения (сценарии сборки ant / maven, определение продукта в случае приложений RCP).И наконец, подумайте об определении всех тестовых случаев в отдельных проектах.Для тестирования иногда требуются специальные библиотеки и файлы ресурсов (конфигурации регистратора, дампы базы данных с тестовыми данными), и эти файлы не должны смешиваться с файлами конфигурации приложения и библиотеками.