Эффективно управляйте весенними зависимостями

Question

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

Предположим, что B зависит от A (фасоль весны).

В прошлый раз мы были ситуации, когда

• «интерфейс» А был изменен, и B перестал работать во время выполнения,
• поведение было изменено таким образом B продолжал работать, но не как ожидалось ,

Как избежать подобных ситуаций? Меня интересуют процессы, программные решения или рекомендации.

Answer 1

Непрерывная интеграция и набор тестов должны быть частью решения. Когда A изменяет все, что зависит от A, проверяется повторно.

Следующее - убедиться, что общедоступность (т. Е. Используется вне его проекта), как известно, является общедоступной, поэтому, когда происходят изменения, все, кто должен знать, знает. Посмотрите на разделение ваших команд и базы кода. Должны ли A и B обрабатываться одной командой? Должны ли они быть частью одной и той же базы кода?

Answer 2

Похоже, вам нужно написать лучшие блок-тесты для проекта. Чтобы взять ваш пример, когда компонент A изменит модульный тест для B, он должен потерпеть неудачу (тест на A завершится неудачно). Я бы рекомендовал писать хорошие тестовые примеры модулей, потому что нет другого способа предотвратить запросы на изменение.

Answer 3

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

Number1:

согласно Spring Framework Best Practices:

Не злоупотребляйте инъекции зависимостей:

В последний момент Spring ApplicationContext может создавать Java объекты для вас, но не все объекты Java должны создаваться за счет зависимости инъекции. Например, объекты домена не должны создаваться через ApplicationContext. Spring - отличная инфраструктура, но, насколько это касается читаемости и управляемости, конфигурация на основе XML может стать проблемой при определении множества bean-компонентов. Чрезмерное использование инъекции зависимостей сделает конфигурацию XML более сложной и раздутой. Помните, что с мощными IDE, такими как Eclipse и IntelliJ, код Java намного проще читать, поддерживать и управлять , чем файлы XML!

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

Меня интересуют процессы, программные решения или рекомендации.

, если вы решите использовать инъекции зависимостей, есть некоторые другие подсказки:

Номер 2:

Предпочитает сеттер инъекцию через инъекцию конструктора:

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

Номер 3:

если B1, B2, ..., Bn зависит от А и А было изменено часто используется класс фабрики (AFactory) и зависят (Bi) s к AFactory фасоли вместо из боба. то для каждого изменения в создании компонента, только Afactory затрагивается, а другие би-бины не изменяются.

поведение А было изменено, так что B продолжал работать, но не так, как ожидалось. Вы можете управлять этими неудобствами, проведя соответствующие тесты интеграции.

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