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

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

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

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

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

Ответы [ 7 ]

12 голосов
/ 13 мая 2015

Разделение интересов

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

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

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

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

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

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

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

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

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

Проектные ссылки в Eclipse

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

Project references menu

7 голосов
/ 13 мая 2015

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

Итак, если вы

  • используйте простой Eclipse для сборки и любите все просто, просто добавьте третий проект и добавьте зависимость.
  • используйте osgi, вы уже правильно создали новый проект osgi.
  • используйте инструмент сборки, например, maven или gradle, затем настройте многопроектную сборку.
5 голосов
/ 13 мая 2015

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

1 голос
/ 19 мая 2015

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

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

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

1 голос
/ 14 мая 2015

Вам необходимо создать другой проект (т.е. общий). Все мои приложения для СЕРВЕРА-КЛИЕНТА мне нравятся.

Here is a sample of an EJB app

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

0 голосов
/ 18 мая 2015

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

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

классическим способом сделать это было бы использование 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 with gitflow:

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

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

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

0 голосов
/ 08 сентября 2011

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

Если вам нужно совместно использовать доменные объекты, забудьте о REST, это доставит мне больше хлопот, чем стоит.

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