Какая часть приложения должна отвечать за уведомление клиентов SignalR?

Я использую RavenDB, и мой DAL получает уведомление, когда определенные документы добавляются в базу данных. Весь поток выглядит так:

WPF -> WCF (хосты тоже SignalR) -> BLL -> DAL -> RavenDB

Когда документ добавлен, вот что происходит:

  1. Документ RavenDB добавлен
  2. DAL получает уведомление об изменении и запускает событие
  3. WCF подписывается на это событие и отправляет сообщение всем клиентам SignalR
  4. Все клиенты WPF получают это уведомление и обновляют интерфейс, чтобы показать этот новый документ

Это кажется неправильным, потому что моя служба WCF имеет прямую зависимость от DAL.

Другой вариант - заставить DAL уведомить клиентов SignalR, но тогда это может показаться неправильным, поскольку DAL не должен беспокоиться об этом. Должно ли это?

Какая часть всего приложения должна отвечать за фактическое использование SignalR для уведомления всех подключенных клиентов?

Чтобы быть ясным, часть, с которой я испытываю трудности, - красная линия (#2) ниже. Я с трудом позволяю службе WCF зависеть от DAL.

введите описание изображения здесь

Источник

3 ответа

Решение

Ваш сервис, несомненно, зависит от вашего BLL, который, в свою очередь, зависит от права DAL? Почему бы не направить событие из вашего DAL, а затем через ваш BLL, чтобы это было событие в BLL, на которое подписывается сервис?

Источник

Я создал независимый способ обновления клиентов SignalR, моя библиотека находится на nuget. Установка с использованием

Install-Package SignalR.EventAggregatorProxy

Вики: https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy/wiki

Для работы фреймворка нужна служебная шина или "EventAggregator", я не прописал его жестко для конкретной служебной шины или агрегатора событий, поэтому вам нужно создать для него прокси-сервер, Caliburn micro имеет легковесный агрегатор событий процесса, который вы можете установить с помощью

Install-Package Caliburn.Micro.EventAggregator

Затем вам нужно создать прокси между моей библиотекой и CM.EA, после чего любое сообщение, опубликованное на вашем уровне доступа к данным, будет автоматически отправлено клиентам. Они могут слушать такие события, как

signalR.eventAggregator.subscribe(MyApp.Events.TestEvent, this.onTestEvent, this);

Вы также можете использовать общие события, такие как

signalR.eventAggregator.subscribe(MyApp.Events.MyGenericEvent.of("System.String"), this.onMyGenericEvent, this);

редактировать: только что понял, что вы используете WPF, а не JS для клиентов, извините за это. В настоящее время библиотека предназначена для веб-приложений. Но, конечно же, это должно работать и для клиентов C#, сразу же добавит поддержку клиентов C#!

Обновление: теперь доступен клиент.NET, сервер по-прежнему размещен только на IIS.

Install-Package SignalR.EventAggregatorProxy.Client.DotNet

Вики: https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy/wiki/.NET-Client

Класс.NET может прослушивать подобные события

public class MyViewModel : IHandle<MyEvent>
{
   public MyViewModel(IEventAggregator eventAggregator) 
   {
      eventAggregator.Subscribe(this);
   }
   public void Handle(MyEvent message)
   {
      //Act on MyEvent
   }
}

Смотрите вики для получения дополнительной информации

Источник

Ваш рабочий процесс мне кажется нормальным, но я полагаю, что это зависит от того, как скоро SignalR получит уведомление. Если бы это был я, я бы обновил клиентов из WCF, как только смог. Возложение ответственности за отправку сообщения всем клиентам на уровень DAL - это не то место, где нужно это делать.

Источник
Другие вопросы по тегам