WedX - журнал о программировании и компьютерных науках

.NET Remoting to WCF — структурирование решения, позволяющее избежать круговой зависимости

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

  • UI
  • Бизнес-уровень

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

Для .NET Remoting эта ситуация идеальна. Распределенная часть — это просто служба 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?


  • Для некоторых проектов я использовал этот метод с большим успехом. 05.07.2011

Ответы:


1

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

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

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

04.07.2011
  • Я действительно не понимаю. В моем случае что-то должно создавать эти объекты IJobProcessor. То, что конкретно создается, является частью бизнес-логики. 05.07.2011
  • Если у вас есть метод на уровне службы, ожидающий параметры, параметр создается путем десериализации клиентского запроса. Все остальные классы бизнес-уровня создаются либо в самой операции службы, либо в загрузчике уровня службы. 05.07.2011
  • Новые материалы

    Объяснение документов 02: BERT
    BERT представил двухступенчатую структуру обучения: предварительное обучение и тонкая настройка. Во время предварительного обучения модель обучается на неразмеченных данных с помощью..

    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..

    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..

    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..

    Использование машинного обучения и Python для классификации 1000 сезонов новичков MLB Hitter
    Чему может научиться машина, глядя на сезоны новичков 1000 игроков MLB? Это то, что исследует это приложение. В этом процессе мы будем использовать неконтролируемое обучение, чтобы..

    Учебные заметки: создание моего первого пакета Node.js
    Это мои обучающие заметки, когда я научился создавать свой самый первый пакет Node.js, распространяемый через npm. Оглавление Глоссарий I. Новый пакет 1.1 советы по инициализации..

    Забудьте о Matplotlib: улучшите визуализацию данных с помощью умопомрачительных функций Seaborn!
    Примечание. Эта запись в блоге предполагает базовое знакомство с Python и концепциями анализа данных. Привет, энтузиасты данных! Добро пожаловать в мой блог, где я расскажу о невероятных..


    Для любых предложений по сайту: wedx@cp9.ru