Решение круговой зависимости

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

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

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

Ответ 1

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

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

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

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

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

Теперь они развязаны =)

Ответ 2

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

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

Ответ 3

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