Welche mvc3 / c# Technologie/Architektur sind wir wirklich auf der Suche nach - nservicebus, WCF oder etwas anderes?

Question

Wir müssen Folgendes tun.

Wir haben eine Webanwendung (MVC3), mit der verschiedene Entitäten verwaltet werden können. Sagen wir "Schulen", "Schüler" und "Lehrer".

Wenn sich eine dieser Entitäten ändert (erstellt, aktualisiert oder gelöscht wird), müssen wir ein anderes System über diese Änderung informieren. Wir haben keine Kontrolle über dieses andere System, aber wir haben Zugang zu einem Webdienst, mit dem wir es in Echtzeit aktualisieren können.

Ich weiß, dass ich nicht möchte, dass unsere Benutzer warten müssen, während wir eine Verbindung zu diesem Webdienst herstellen und die Aktualisierungen vornehmen, also brauchen wir eine Möglichkeit, Aktualisierungen in eine Warteschlange zu stellen und die Änderungen als Teil eines völlig separaten Prozesses vorzunehmen.

Ich wäre wirklich dankbar für jeden architektonischen Hinweis zur Lösung dieses Problems. Ich bin mir sicher, dass es bestehende Frameworks gibt, die diese Warteschlange verwalten und uns z. B. Daten erneut senden lassen, wenn die Kommunikation unterbrochen wird - aber ich weiß nicht, welche Frameworks ich mir ansehen soll.

Cheers!

Answer 1

NServicebus würde die von Ihnen benötigte Warteschlangenbildung ermöglichen. Es bietet Transaktionsunterstützung und ein Dienstprogramm für die Rückkehr zur Ausgangswarteschlange für den Fall, dass Sie eine fehlgeschlagene Nachricht erneut verarbeiten müssen. Ich würde hier ein drittes System empfehlen, das sich um den Aufruf des Webdienstes kümmert. Dieser Message-Handler würde aus der Warteschlange lesen und den Webdienst aufrufen.

Client -> Veröffentlichen NServiceBus Msg -> MessageHandler -> Web Service

Mit diesem Message-Handler haben Sie dann die von Ihnen gewünschte Funktionstrennung.

Answer 2

Der andere Anbieter/Client, der Datenaktualisierungen benötigt, ist nicht von Ihrer Anwendung abhängig. Zumindest nicht von Ihrer Erklärung. Er ist auf genaue Daten angewiesen. Das heißt, Ihr Problem ist ein Datenproblem und kein Anwendungsproblem. Von diesem Standpunkt aus betrachtet, sieht eine Datenlösung sehr attraktiv aus.

Wenn Sie SQL Server verwenden, würde ich in Erwägung ziehen, Trigger in der Datenbank zu verwenden und dort zu initiieren. Wenn Sie die Arbeit sowohl von den Datenbankoperationen als auch von der Anwendung vollständig entlasten wollen, eignet sich der SQL Server Service Broker hervorragend.

Wenn Sie mit einer anderen Datenbankplattform arbeiten, haben Sie vielleicht einen Warteschlangendienst oder auch nicht. In diesen Fällen benötigen Sie möglicherweise einen Servicebus, aber ich würde sehen, ob es eine einfachere, zuverlässige asynchrone Methode gibt, die Sie zuerst verwenden können.