Циклические зависимости - опять же

Question

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

Edit:

Я понимаю, это может быть исправлено с помощью только одного узла. У нас есть более одного по следующей причине:

• наша «система» состоит из нескольких компонентов. Клиент может иметь только один компонент или более - так что мы сделали, мы создали разные сборки для разных компонентов. Это имеет смысл - зачем вам разворачивать то, что вам не нужно, разве это не трата памяти?
• То, что было общим для большего количества компонентов, в основном вспомогательных классов, перешло на другую сборку - снова не всем компонентам нужны все вспомогательные классы, поэтому есть больше сборок
• Однако эти два приложения могут разговаривать друг с другом - система для врачей отправляет запросы в систему для медсестер, запросы возвращаются и т. д. - и вот где фактическая проблема

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

Теперь у нас есть 8-10 сборок, и похоже, что чем больше у вас есть, тем быстрее они добавляются :) - например, мы добавили универсальную функцию, которая использует пользовательские атрибуты, - поэтому мы добавили еще одну сборку только для атрибут - на случай, если мы не столкнемся в конфликте в будущем

Это путь? Я действительно чувствую, что мы делаем что-то принципиально неправильное :)

Я очень ценю ваш вход.

Answer 1

Я бы попытался вытащить обидные типы в третью «общую» сборку, с которой ссылаются две «родительские» сборки.

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

Пожалуйста, попробуйте добавить больше контекста на ваш вопрос - возможно, есть некоторые детали, с которыми мы можем помочь, если мы точно знаем, что вы пытаетесь сделать.

Edit повторно ваши дополнения: Для того, чтобы конкретно ответить на ваш вопрос относительно того, или нет несколько сборок является путем, подумайте: я когда-то работал на кодовом как это с Visual Studio 2008, где было около 20 отдельных файлы проекта открываются в решении сразу. Эти 20 проектов поддерживали DLL для одного основного EXE. Эти проекты не распространялись на другие продукты, и не было странных требований к версированию.

Работа с этим решением была кошмаром. Visual Studio составляла буквально 5 минут для компиляции решения. Компиляция в командной строке с MSBuild заняла 2 минуты. Это сделало постепенное изменение упражнений в расстройстве и боли. Поскольку все проекты использовались при создании основного исполняемого файла, ни один из них не мог быть выгружен, чтобы ускорить компиляцию, и существует исполнительный мандат по разрыву проектов на отдельные решения.

Если у вас есть такое единственное решение, поверьте мне, когда я скажу, что вы и ваши товарищи по команде восстаете в один прекрасный день ... Моя рекомендация заключалась в том, чтобы разбить сборки на свои собственные решения, объединив любые сборки, которые скорее всего, будут изменены вместе; затем создайте задачу пользовательской сборки, которая копирует окончательную сборку в общую папку, из которой все остальные сборки могут принимать ссылки.

Answer 2

Можете ли вы поместить обычные вещи в свою собственную сборку?

Я согласен с одним комментатором в том, что нам, вероятно, нужна дополнительная информация.

Почему у вас есть 2 ассамблеи?

Есть ли причина, по которой все не в одной сборке?

Как соединяются эти сборки? Просто через ссылку или есть WCF и т. Д. Компоненты?

Мы дали вам самые простые ответы, но, возможно, есть еще что-то, чем мы можем сказать по вашему краткому описанию.

Answer 3

Один из способов избежать использования прокси/бизнес-структуры.

AssemblyA.Proxy - содержит два класса: один интерфейс (назовем его IServices), а другой класс, отвечающий за вызов AssemblyA.Business методы.

AssemblyA.Business - содержит один класс, который реализует методы, объявленные на IServices.

AssemblyB.Proxy - аналог AssemblyA.Proxy

AssemblyB.Business - аналог AssemblyA.Business

Таким образом, каждый компонент прокси будет ссылаться только на бизнес-логике, они должны к. AssemblyA.Proxy будет иметь ссылку на AssemblyA.Business; AssemblyB.Proxy будет иметь ссылку на AssemblyB.Business. AssemblyA.Business будет ссылаться на AssemblyB.Proxy и так далее.

Не знаю, ясно ли это, но надеюсь, что это поможет.