Подтвердить что ты не робот

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

Мы разрабатываем веб-приложение, состоящее из двух проектов Eclipse. Один проект - веб-служба RESTful, основанная на HTTP; другой проект - это веб-сайт. Оба будут развернуты как WAR. Первоначально оба будут развернуты под одним и тем же экземпляром сервера приложений, но в конечном итоге они будут находиться в отдельных блоках.

Приложение веб-сайта использует приложение RESTful WS. Очевидно, что будут коды, в частности, классы домена, которые являются общими для обоих проектов. Например, может существовать ресурс, расположенный в <app> /users, который предоставляет операции CRUD для объектов User; чтобы обновить пользователя, приложение веб-сайта выполнило бы POST объект XML-сортированного пользователя для <app> /users. Выполнение GET для <app> /users/1 приведет к возврату объекта UserMarkalled User.

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

Изменить: Удалены ссылки RESTful. Семантика в стороне, каков правильный способ совместного использования общего кода между двумя проектами Eclipse?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Project references menu

Ответ 2

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

Итак, если вы

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

Ответ 3

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

Ответ 4

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

Here is a sample of an EJB app

Базовый, общий модуль имеет интерфейсы 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/

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

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