AngularJS Comet («в реальном времени») приложение двухсторонняя межмодульная связь

Question

У меня есть большой комплекс AngularJS Comet application («в режиме реального времени»). Клиенты отправляют данные на сервер, а также получают уведомления с сервера о событиях, которые инициировали другие пользователи.

В своей простейшей форме, приложение имеет следующие клиентские компоненты ("Service" ниже может быть AngularJS .Service или .factory, независимо)

• [Object] Controller: может быть любой объект, как Student, Teacher , Lesson, Document
• [Object] Service: удерживает модель объекта и имеет методы для работы с этими данными
• Socket Service: обертка для библиотеки сокета

Вызовы могут идти в обоих направлениях

• Пользователь Обновления Что-то>[Object] Controller>[Object] Service>Socket Service> Сервер
• Сервер>Socket Service>[Object] Service>[Object] Controller> Пользователь Заявленный

Что является лучшим архитектура для двусторонней межмодульной связи в этом случае?

Вот что я думаю о вариантах. Пожалуйста, предложите другие хорошие, если я их оставил.

1. Используйте circular dependency fudge. Всюду, где я читал, кажется, что мы не должны этого делать, включая Lu4 в его «выдумке». С другой стороны, это означает, что вы можете иметь вызовы методов в обоих направлениях, поддерживая межмодульную связь во всем приложении.
2. Используйте инъекции зависимостей и вызовы методов в одном направлении и события в другом направлении. Есть someopposition событиям с чрезмерным использованием. Это случай чрезмерного использования?
3. Используйте события в обоих направлениях. Подходит ближе к «чрезмерному использованию», но поддерживает взаимодействие между модулями в приложении.
4. Используйте Mediator pattern, т. Е. Иметь центральное устройство для координации, которое координирует в обоих направлениях. Я не уверен, как это отличается или лучше, чем использование событий, в которых $ rootScope становится «посредником», против которого регистрируются все события и их обратные вызовы.
5. Какая-то длительного опроса между модулями, так что, например, [Object] Controller делает вызов [Object] Service, который возвращает обещание и в свою очередь, вызывает Socket Service, который также возвращает обещание, и когда Socket Service получает некоторые данные, обещание устраняющее назад вверх по цепи, после чего [Object] Controller инициирует другой запрос.

Answer 1

Чистым решением будет использование классического ДИ для направления, инициированного пользователем. Так как ваша [Object] Service содержит модель, вам нужно только обновить ее (если ваша реализация в противном случае будет чистой, т. Е. Вы будете использовать объект с введенной моделью везде).

Таким образом, проблема сводится к тому, как получить новые обновления из службы Socket в службу [Object].Так как ваша служба Socket действительно не должна знать о ваших моделях. Детализация моделей не является разумным решением (оставьте только созданную круговую зависимость). Получение обновления с сервера для чего-либо в вашем клиентском приложении находится в самом определении события (может произойти в любое время), поэтому я думаю, что очень разумно получить $RootScope в вашем SocketService и транслировать его. В этом случае ваши [Объектные] Услуги берут, чем заботятся об обновлении моделей на основе новой информации.

Если у вас есть много сервисов, и обычно события, инициированные сервером, относятся только к одному или нескольким из них, возможная оптимизация будет заключаться в том, чтобы отправить поле с сервера, на модели которого влияет это обновление. Это разумно, так как сервер уже знает о моделях, и он позволяет службе Socket транслировать события updateFor: xxx, не зная о том, что означает xxx. Соответствующая функция [Object] затем прослушивает только событие updateFor: [Object]. Но, как всегда, с оптимизацией, не делайте их, если простой способ уже работает для вас.