2016-05-18 5 views
0

У меня есть проект Spring, который содержит ~ 50 компонентов. К сожалению, один из классов вызвал проблему циклической зависимости в Maven. Вот история:Проблема с циклической зависимостью Maven для проекта Spring

Я добавил новый компонент к моему проекту Spring. Назовем это Apple пока. Он имеет @Bean под названием AppleWatch. Одна из реализаций, что Apple жил (зависит) от другого компонента: Foxconn, так что AppleWatch может вызвать метод в Бина называется CheapLabor.

В то же время, CheapLabor зависит от другого компонента: Corning. Для работы сверхурочно требовалось GorillaGlass.

Все было очень хорошо до того момента, Corning понимает, что он хочет, чтобы сэкономить деньги, делая подобное количество очков в соответствии с потребностями рынка в Apple. Поэтому он пытается назвать метод getCurrentMarketOrders() in AppleWatch. Для этого я подготовил фасоль AppleWatch в класс GorillaGlass.java. Затем ...

Boom! Ошибка циклической зависимости!

Таким образом, любое предположение о том, что я должен сделать для Apple и/или Corning?

+0

Обычным советом было бы зависеть от интерфейсов, а не от реализации - я подозреваю, что это поможет. Кроме того, подумайте о направлении ваших зависимостей. Например, я вижу часы в зависимости от стеклянного кристалла, но не наоборот. Это похоже на то, что ваш класс GorillaGlass каким-то образом зависит от AppleWatch - заставляет меня царапать голову, но, возможно, я просто неправильно понимаю проблему. – unigeek

+0

Является ли это ошибкой времени сборки или ошибкой времени выполнения (включая модульные тесты)? –

+0

@unigeek Я согласен. Реконструкция структуры проекта, соответственно, решает проблему.Но оказалось, что я не мог изменить структуру, не сводя с ума своих боссов/коллег. Существует множество подходов к решению проблем циклической зависимости. Я придумал это в конце: двигая логикой, что 'Corning' зависит от' Apple', чтобы быть частью 'Apple': вместо получения необходимой информации от' Apple', 'Coring' теперь получает эту информацию из' Foxconn' , который вызывает метод из 'Apple'. Он разбивает круг на 'Apple' ->' Foxconn' -> 'Corning'. Не лучший ход, но он сработал. –

ответ

0

Как уже упоминалось, @unigeek, интерфейсы - ваши друзья в этом случае. И в контексте структурирования вашего проекта maven это означает разделение интерфейсов на отдельные модули API maven.

Вскоре Corning поймет, что он также поставляет GorrilaGlass в Samsung, а не только Apple. Так что теперь его нужно позвонить getCurrentMarketOrders() не только на AppleWatch, но и Gear2. Решение становится более понятным на данный момент: введите API-модуль с интерфейсом Marketable, который зависит как от Apple, так и от Samsung, что позволяет реализовать AppleWatch и Gear2. Marketable. Тогда Corning просто зависит от этого нового модуля API, не имея прямых зависимостей ни от Apple, ни от Samsung, а последние оба предоставляют свои собственные реализации этому интерфейсу.

Смежные вопросы