Круговая зависимость решения

Question

Наш текущий проект столкнулся с проблемой циклической зависимости.Наша сборка бизнес-логики использует классы и статические методы из нашей сборки SharedLibrary.SharedLibrary содержит целый набор вспомогательных функций, таких как класс SQL Reader, перечислители, глобальные переменные, обработка ошибок, ведение журнала и проверка.

SharedLibrary требуется доступ к бизнес-объектам, но бизнес-объектам нужен доступв общую библиотеку.Старые разработчики решили этот очевидный запах кода, реплицировав функциональность бизнес-объектов в общей библиотеке (очень анти-СУХОЙ).Я провел целый день, пытаясь прочитать о моих вариантах решения этой проблемы, но я зашел в тупик.

Я открыт для идеи редизайна архитектуры, но только в качестве последнего средства.Итак, как же я могу получить библиотеку Shared Helper, которая может обращаться к бизнес-объектам, при этом бизнес-объекты все еще обращаются к библиотеке Shared Helper?

Answer 1

Вы можете создать отдельный проект только для объектов-значений (без логики) и интерфейсов .

Ваши классы общей библиотеки реализуют интерфейсы , а бизнес-библиотека зависит от интерфейсов (слышу ли я здесь более тестируемый и отсоединенный код? Не говоря уже о том, что вы удалили зависимость из общей библиотеки).

В идеале, вы могли бы иметь бизнес-объекты, от которых ваша общая библиотека зависит также и от этого дополнительного проекта. Если бизнес-объекты слишком сложны, вы также можете преобразовать их в интерфейсы.

У вас будут оба проекта, не зависящие друг от друга, но только от другого проекта, в котором есть только «фиктивные» объекты (без логики):

Business ---> Интерфейсы и объекты-значения <--- Общая библиотека </p>

Теперь они отделены =)

Answer 2

Каждый раз, когда у вас есть «разделяемая» библиотека, вы абсолютно не должны ссылаться на свой проект бизнес-объекта. Это приведет к возникновению этой проблемы, как вы, очевидно, видите.

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

Answer 3

Одним из решений было бы поместить фасадный рисунок между ними. Здесь вы бы избегали прямого доступа / зависимости к вашим бизнес-объектам из общей библиотеки. Вместо этого вы будете использовать слой, который действует как фасад между вашей lib и BO. Таким образом, вы можете упаковать свои общие библиотеки в чистом виде и отсоединить их.