Подтвердить что ты не робот

Как бороться с циркулярными ссылками?

Если у меня есть два проекта:

MyCompany.ERP.Billing
MyCompany.ERP.Financial

Фактурирование запрашивает/отправляет информацию в Финансовый и наоборот. Оба они слишком большие, поэтому я не хочу ставить их в один проект. Visual Studio не разрешает круговые ссылки. Как вы справитесь с этим?

4b9b3361

Ответ 1

Извлеките интерфейсы из своих классов и поместите их в основной проект, на который ссылаются как из проектов Billing, так и Financial. Затем вы можете использовать эти интерфейсы для обмена данными между сборками.

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

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

Ответ 2

Слишком большой проект не должен быть проблемой. Вы можете сохранить свой код структурированным с пространством имен и разными папками для исходного кода. В этом случае круговые ссылки больше не являются проблемой.

Ответ 3

Ответ, указывающий на интерфейсы, правильный, но если вам нужно создать оба типа из обоих проектов, вам нужно будет объединить factory в еще один проект (который также будет ссылаться на проект интерфейсов, но могут быть указаны обоими вашими основными проектами) или изменить структуру, которую вы используете значительно.

Что-то вроде этого должно работать:

Finance: References Billing, Interfaces, Factory
Billing: References Finance, Interfaces, Factory
Factory: References Interfaces

Factory будет иметь BillingFactory.CreateInstance() As Interfaces.IBilling, а также абстрактный класс Billing, реализующий Interfaces.IBilling.

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

Ответ 4

Это решение может оказаться в качестве обходного пути для круглой справки. В основном вы используете #if логику вокруг кода, который не компилируется, если ссылка не существует, и вы используете условную компиляцию в файле проекта, чтобы определить переменную, только если существует необходимая сборка. В результате при первой загрузке из исходного кода или после чистки решения вы должны скомпилировать его дважды. Последующие сборки/перестройки требуют только 1 сборки как обычно. Самое приятное в этом - вам никогда не придется вручную комментировать/раскомментировать инструкции #define.