2013-04-16 15 views
8

Ich habe ein Projekt, das ich gerade mit BreezeJS eingerichtet habe. Ich weiß nicht, was in BreezeJS in vollem Umfang vor sich geht, aber ich habe einfach akzeptiert, dass es funktioniert. Ich habe meine Objekte auf dem Bildschirm im Wesentlichen von diesem einfachen Befehl aus gesehen.SignalR kombiniert mit Breeze

export function getProjects(projectsObservable, errorObservable) 
{ 
return breeze.EntityQuery.from("Projects") 
     .using(manager).execute()...then/fail. 
} 

Ich möchte jetzt reagieren auf Benutzer, die die gleichen Elemente mit signalR bearbeiten. Das bedeutet, ich habe an dieser Stelle Callbacks ausgelöst Javascript Ende, dass Objekt mit GUID = xxxxxxx hat sich geändert (GUID ist der Schlüssel).

Wie kann ich in Breeze tippen, aktualisieren Sie das Element, ohne es erneut den Server abfragen, noch sieht es als ein Update, das an den Server zurück gesendet werden muss. Denken Sie daran, dass ich gerade das Update von Signal r bekommen habe.

Sollte ich an erster Stelle einen anderen Pfad genommen haben, gibt es einen Grund, ein WebApi zu erstellen, wenn ich nur die Daten vom SignalR Hub am Anfang hätte zurückgeben können? Wäre es einfach, dies mit Breeze anstelle von WebApi einzurichten?

Antwort

12

Wir bei IdeaBlade freuen uns darauf, Ihnen eine gute Anleitung für Breeze-Apps zu geben, die mit SignalR arbeiten.

Mein aktuelles Denken ist, dass SignalR geeignet ist für den Kunden von Änderungen an Daten von Interesse anmelde aber ich würde nicht die geändertenen Daten an den Client mit SignalR liefern. Ich lasse den Client entscheiden, ob (oder nicht ... oder wann) die geänderten Daten vom Server abgerufen werden sollen.

Meine Argumentation basiert auf der Ansicht, dass SignalR ein schneller, leichter Mechanismus für die Benachrichtigung sein sollte, nicht ein Feuerschlauch, der große Datenmengen bei abonnierenden Kunden sprüht, die bereit oder willens sind, mit einem System umzugehen große Menge an Änderungsdaten, die ihnen aufgezwungen wurden.

Vielleicht können Sie näher erläutern, warum Sie anders denken. Ich bin offen für eine alternative Perspektive.

+0

Erstens wäre es Einfachheit und schnelle Entwicklung. Einfach an den Signalgeber anschließen, um Daten zu übertragen.Aber Sie haben absolut Recht, dass es besser sein könnte, den Kunden entscheiden zu lassen, wann er die tatsächlichen Daten erhalten soll. Ich werde ein wenig mehr darüber nachdenken, und wenn ich meine Meinung ändere, dass meine erste Idee besser ist als deine, dann werde ich es euch wissen lassen :) –

+0

Ich muss mit dem Aufstieg von CQRS sagen, dass diese Ansicht nicht die einzig korrekte Ansicht ist. Wenn ich Befehle an meinen Server erhalte, die mir schließlich Ereignisse/oder vollständige Lesemodelle schicken, dann ist der Signalgeber ein großer asynchroner Ereignis- und Objektliefermechanismus. – Damian

+0

Eigentlich wäre dies ein großartiges Feature aus dem gleichen Grund, Brise Changesets ist - Minimierung der Anzahl der Roudrips auf dem Server. Wenn Sie nur Signalgeber für Benachrichtigungen verwenden (was auch nicht frei ist), müssen Sie immer noch alle geänderten Objekte, an denen Ihr Client interessiert ist, über die Web-API/ODATA abrufen. In nicht-trivialen Fällen würde dies mehrere Anfragen oder eine dedizierte Methode erfordern die Änderungen in einem Zug, die wiederum nicht flexibel/generisch sein können. Mein Punkt ist - es wäre schön, eine Möglichkeit zu haben, Changesets nicht nur auf dem Server, sondern auch auf abonnierten Clients (optional) zu propagieren. –

4

Ich bin völlig einverstanden mit Ward Glocke

Wenn Sie sich fragen, wie es zu tun: zum Beispiel in einem Winkel Anwendung, können Sie abonnieren Entity-Tracking-Mechanismus wie dieser

enter image description here

Brise Dann könnten Sie einen SignlarR Hub an einem anderen Ort einrichten, um diese Änderungen an alle Clients zu senden.

Allerdings möglich dank der Kraft von bree ze.js, Ich würde es nicht empfehlen, weil, wie Ward darauf hingewiesen: "das wird ein Feuerschlauch Spritzen große Mengen von Daten bei abonnierenden Kunden sein". Denken Sie nur einen Moment nach, und denken Sie daran, dass Ihre Anwendung hmmm ist, lassen Sie uns sagen, 30 gleichzeitige Benutzer, die Transaktionen durchführen, stellen Sie sich den gesamten Netzwerkverkehr vor, der erstellt wird. Das wird eine schlechte Software-Architektur sein. Der einzige Grund, warum Sie dies in Betracht ziehen sollten, ist, wenn Sie ein Dashboard aktualisieren müssen, das von Live-Daten gespeist wird, aber dennoch müssen Sie besonders präzise, ​​bewusst, bewusst sein und den Datenverkehr und die Serverauslastung kennen.

function setupEventForHasChangesChanged() { 
     EntityManager.hasChangesChanged.subscribe(function (eventArgs) { 
      $rootScope.$emit('dataservice.hasChangesChanged', eventArgs); 
     }); 
    } 

    function setupEventForEntitiesChanged() { 
     EntityManager.entityChanged.subscribe(function (changeArgs) { 
      if (changeArgs.entityAction === breeze.EntityAction.PropertyChange) { 
       $rootScope.$emit('dataservice.entitiesChanged', changeArgs); 
      } 
     }); 
    } 
+2

Veröffentlichen Sie keine Screenshots des Codes. Veröffentlichen Sie den Code als Text. –