Каков наилучший способ совместного использования общего кода (например, классов домена) между двумя или более проектами?

Ответ 1

Разделение проблем

Фактически создание третьего проекта и добавление зависимостей проекта - лучший способ, потому что Разделение проблем - это не только принцип для классов, но и для программных модулей. Это создает некоторые преимущества:

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

Структура проекта

Убедитесь, что вы не создаете один большой проект "утилита", а скорее проекты, специфичные для домена, такие как управление пользователями или адресная книга.

В вашем случае это может быть

• user-api содержит объект передачи данных
• Пользовательский сервис предоставляет операции CRUD.
• webapp (или пользователь-клиент) вызывает пользовательское обслуживание.

Другие системы сборки

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

Наиболее популярными проектами Build Systems для Java являются Maven, Ant и Gradle. Каждый из них имеет свой собственный способ определения зависимостей модулей.

Ссылки на проекты в Eclipse

Чтобы сообщить Eclipse о зависимостях проекта, щелкните правой кнопкой мыши на проекте, откройте свойства и переключитесь на ссылки проекта. Здесь вы можете пометить зависимости, чтобы изменения кода вступили в силу немедленно без копирования файла JAR вручную.

Ответ 2

Imho, это зависит от вашей системы сборки, а не с вашей IDE.

Итак, если вы

• используйте простой Eclipse для сборки и хотите, чтобы все было просто, просто добавьте третий проект и добавьте функцию dependecy.
• Используйте osgi, вы бы уже создали новый проект osgi.
• используйте инструмент построения, например maven или gradle, затем настройте многопроектную сборку.

Ответ 3

Обычно вы создаете третий проект (например, основной или общий), который содержит общий код. Просто зависните от них от ваших проектов.

Ответ 4

Вам нужно создать другой проект (т.е. общий). Все мои приложения SERVER-CLIENT мне нравятся.

Базовый, общий модуль имеет интерфейсы EJB, которые используются клиентом и реализуемые ejbModule

Ответ 5

Как вы используете сторонние банки? Подумайте о том, что ваш общий код является сторонним банком и применяйте то же правило к вашим проектам. Вы можете использовать инструмент управления зависимостями, например maven, чтобы поддерживать порядок версий в порядке.

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

Вы также можете попробовать OSGI.

Ответ 6

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

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

Ответ 7

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

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

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

project-parent
    project-website1
    project-website2
    project-controllers
    project-model
    [...]

внутренне, эти модули могут затем зависеть друг от друга. вы можете зайти так далеко, как отделить интерфейсы от реализации:

project-parent
    project-website1
    project-website2
    project-api
    project-api-impl
    [...]

а затем в большинстве случаев в зависимости от модуля api. maven также имеет несколько механизмов для работы с файлами WAR.

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

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

другой шаблон будет выглядеть следующим образом:

 project1-parent
      project1-webapp
      project1-specifics
      [...]

 project2-parent
      project2-webapp
      project2-specifics
      [...]

 common-parent
      common-api
      common-impl
      common-model
      [...]

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

https://maven.apache.org/

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

https://gradle.org/

чтобы максимально использовать их, вы также можете изучить git с помощью gitflow:

http://git-scm.com/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/

и понять, как использовать это, чтобы справиться с версированием и выпуском.

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