.NET Remoting для WCF - Структурирование решения, чтобы избежать циклической зависимости

Question

Я пытаюсь преобразовать существующий проект, который использует .NET Remoting, чтобы использовать WCF.Структура проекта следующая:

• UI
• BusinessLayer

Проект BusinessLayer - это библиотека классов, которая содержит объект, активируемый клиентом DistributedProcessor, который имеет метод IResult Process(IJobProcessor).Интерфейсы IJobProcessor и IResult и конкретные классы находятся в библиотеке BusinessLayer.Конкретные классы IJobProcessor, в свою очередь, используют много, много классов в BusinessLayer.

Для .NET Удаленная работа в этой ситуации идеальна.Распределенная часть - это просто служба Windows, которая содержит BusinessLayer и прослушивает определенный порт.Клиентская сторона создает удаленный объект, используя Activator.GetObject().

. Чтобы преобразовать его в WCF, я понял, что у меня есть проблема циклической зависимости, если я структурирую проект следующим образом:

• UI
• BusinessLayer - ссылки на WcfService
• WcfService - ссылки на BusinessLayer

Службе требуется ссылка на BusinessLayer, чтобы я мог передавать объекты по проводам.BusinessLayer нужна ссылка на WcfService, чтобы он мог вызывать метод IResult Process(IJobProcessor) на WcfService.

Можно ли переместить интерфейсы IResult и IJobProcessor в отдельный проект BusinessLayerDistributed, например:

• UI
• BusinessLayer - ссылки BusinessLayerDistributed
• BusinessLayerDistributed
• WcfService - ссылки BusinessLayer, BusinessLayerDistributed

Мой вопросявляется: Если конкретные классы для всех этих интерфейсов все еще находятся в BusinessLayer, будут ли объекты IResult и IJobProcessor правильно гидратированы как их конкретный класс при передаче в службу?Есть ли уловка, чтобы сделать это с WCF?

Answer 1

Почему бизнес-уровень должен вызывать что-либо в сервисном уровне?Бизнес-уровень не должен обладать какими-либо знаниями о слое фасадов сервисов, а обычные сервисы вызываются из клиента - никогда из бизнес-уровня, потому что это не имеет смысла в архитектуре сервисов.

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

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