Argumente für die Verwendung von WCF/OData als Zugriffsschicht anstelle von EF/L2S/nHibernate direkt

Question

Wir entwickeln meist wenig frequentierte, aber hochspezialisierte Webanwendungen. Normalerweise verwenden wir L2S, EF oder nHibernate als Zugriffsebene und werfen dann Asp.Net MVC dorthin und in dem wir für normale Crud-Operationen den ISession/DataContext direkt abfragen, aber für fortgeschrittene Funktionen/Nebeneffekte stellen wir es in eine Art von Serviceschicht.

Jetzt habe ich darüber nachgedacht, die Daten über OData (WCF Data Service) zu veröffentlichen und diese von den Controllern (oder sogar von jQuery, wenn eine gute Template-Engine auftaucht) abzufragen und die Service-Operationen über einen WCF-Service zu veröffentlichen (oder als benutzerdefinierte Methoden im WCF Data Service?). Welche Vorteile/Nachteile birgt diese Architektur?

Erhalte ich etwas außer höherer Komplexität und Latenz? Bessere Trennungen von Bedenken (oder ist es nur eine Illusion)?

Bearbeiten: Kann es eine gute Idee sein, eine komplette Ajax-gesteuerte Lösung mit z. WCF RIA Services? Oder verliert man zu viel Flexibilität? Fühlt sich so an, als könntest du deine Ansichten komplett von deiner Logik loswerden, dann sollte man in der Lage sein, einfach reines HTML zu schreiben, nicht einmal ein asp.net MVC sollte benötigt werden? aber ich denke, es gibt viele neue Probleme, die entstehen?

Answer 1

Wie TomTom erwähnt, möchten Sie die Kosten für Loopback für OData nicht bezahlen, wenn sie sich innerhalb eines Prozesses befinden. Wenn Sie eine direkte Sichtverbindung zu Ihrer Datenbank haben und es sich um die Datenbank Ihrer eigenen Anwendung handelt, besteht kein Grund, WCF Data Services in die Mitte zu stellen. Ich würde weiterhin eine der anderen erwähnten Optionen verwenden (L2S, EF, nHibernate).

Jetzt, wenn Sie Daten über Ihren http-Endpunkt für andere Anwendungen verfügbar machen müssen, oder sogar für Ihre eigene Anwendung, wenn Sie einige jQuery-Code im Client haben, der auf Daten vom Server zugreifen muss, dann definitiv ein OData Endpunkt kann helfen und WCF Data Services ist die einfachste Möglichkeit, einen zu erstellen.

Answer 2

Tun Sie es nicht. Entschuldigung, aber das ist ein dummer übertriebener Ansatz. Sie sind IN EINEM PROZESS und bestehen darauf, eine Netzwerkverbindung zu betreiben UND alle Daten, die Sie übergeben, in XML zu codieren und wieder zurück zu geben, und sie über eine HTTP-Verbindung mit eingeschränkter Abfragesemantik laufen zu lassen? Erzähl es niemandem, den du probiert hast.

Trennung von Bedenken ist hier eine Illusion - Sie ersetzen ein hoch optimiertes Domänenmodell durch eine vereinfachte Datenschicht.

DAS sagte: Ich liebe OData - großartig. Aber es ist keine in Programm-Technologie, es ist eine FRONT END-Technologie, wie ASP.NET MVC - nur nicht für den Endbenutzer, sondern für ein anderes Programm in Ihre Daten zu integrieren. Es sollte in ähnlichen Szenarios verwendet werden und wenn Daten über Vertrauensgrenzen offengelegt werden (z. B. Silverlight ist eine Vertrauensgrenze, da die Anforderungen gefälscht werden können).

Es ist NICHT optimiert, um in Prozess High-End-Anwendung Laufzeitschichten wie NHibernate zu ersetzen.

Answer 3

Um fair zu sein, gibt es Vorteile für diesen Ansatz, die möglicherweise die Leistungsprobleme überwiegen, die zugegebenermaßen enorm sind. Eine auf diese Weise erstellte Anwendung hat um Größenordnungen mehr Latenz und kann bei der Ausführung von Rechenressourcen mehrere Male mehr kosten als eine prozessinterne Lösung.

In Entwicklungsszenarien, in denen die personellen Ressourcen begrenzt sind, könnte dies besser funktionieren. So können Auftragnehmer schnell angestellt werden, um neue Bildschirme oder ganz neue Anwendungen schnell und in jeder gewünschten Sprache zu schreiben. Entwickler können schneller als eine proprietäre selbst entwickelte Lösung auf die Geschwindigkeit kommen.In den Konfigurationsdateien sind keine Passwörter mehr enthalten, eine benutzerdefinierte Sicherheitsschicht wird bei Bedarf hinzugefügt, eine einheitliche Protokollierung und Überwachung wird durchgeführt, und mehrere Datenspeicher werden in einer konsistenten Ressource zusammengefasst. Wenn Sie eine heterogene Plattform haben, brauchen Sie SDKs nicht zu schreiben, sie wurden bereits in vielen wichtigen Sprachen geschrieben. oData funktioniert sehr gut mit MS Excel, was in vielen Organisationen ein großer Gewinn ist. Abhängig von Ihrer Netzwerktopologie ist es möglicherweise günstiger und sogar schneller, über das Internet zu routen, als eine Standleitung zu verwenden, wenn Sie sich in einem Remote-Büro oder hinter einer Firewall befinden (z. B. auf einer Client-Site). .

Bei großen Datasets verliert der Aufwand für die Anforderung und die Verpackung an Bedeutung. Zum Beispiel für Reporting-Szenarien. Obwohl ich noch nie so etwas entworfen habe, kann ich sehen, wo es sinnvoll ist, je nach Unternehmenskultur und verfügbaren Ressourcen oData-Endpunkte intern zu nutzen.

Answer 4

WCF Data Services und OData unterstützen JSON, sodass Sie die Nutzlast minimieren können, indem Sie diese nutzen. Außerdem können Sie mit WCF Data Services Ihren Datenzugriff vollständig steuern. Sie müssen Entity Framework nicht rollen. Sie können alles anpassen. Der Vorteil ist, dass die Protokollstruktur für Sie vollständig mithilfe von WCF Data Services und OData verarbeitet wird. Und den Service von MVC zu konsumieren, ist eine Add-Service-Referenz entfernt. WCF Data Services wird auf WCF ausgeführt, sodass Sie andere Webdienste als nur die OData-Zustellung ausführen können. Daher ist es äußerst flexibel.

Es gibt hier und da Einschränkungen, die mit der Natur von OData sowie der Art und Weise, wie WCF Data Services mit OData umgehen, verbunden sind. Sie sind jedoch ziemlich spezifisch und wenn sie in Ihrer Architektur auftreten, gibt es Möglichkeiten.

Wenn Ihre Lösung für eine einzelne Webanwendung isoliert ist, funktioniert die eingebettete Datenebene in dieser Anwendung gut. Wenn Sie jedoch eine andere App oder einen anderen Prozess benötigen, der auf die Datenschicht oder die geteilte Geschäftslogik trifft, lohnt sich die Erkundung der Option, Ihre Datenschicht in einen WCF-Datenservice zu stellen. Sie könnten beispielsweise ein PowerShell-Skript schreiben, um eine Web-Service-Methode in zwei Codezeilen aufzurufen. Wenn Sie also Domänenlogik haben, die Sie von Ihrer Webanwendung aus und über eine Befehlszeile oder eine geplante Aufgabe ausführen möchten, kann Ihr WCF-Datenservice-Layer dieses Szenario für alle bewältigen, ohne Logik oder Code duplizieren zu müssen.

Viele Möglichkeiten, eine Katze zu häuten. Ich habe beide Ansätze in Geschäftsanwendungen verwendet und würde nicht sagen, dass das eine oder das andere vermieden werden sollte. Sie funktionieren beide gut und bieten viel Wert, ohne dabei nachteilig zu sein.

Answer 5

TomTom hat viele Stimmen und obwohl er nicht falsch liegt, hat er auch nicht recht, trotz seines überzeugenden Tones. In diesem speziellen Fall scheint das OP eine Intranet-App im LOB-Stil zu schreiben, die wahrscheinlich nur durch einen OData-Service behindert wird, der die zugrunde liegende Datenbank nachahmt, aber was ist, wenn er nicht die zugrunde liegende Datenbank nachahmt?

Wenn er eine Anwendung auf der Grundlage verschiedener oder unbekannter zukünftiger Datenquellen erstellt hat, kann die Services-Schicht diese Services vereinheitlichen, neu darstellen, vereinfachen und aggregieren, selbst wenn ein großer Teil der Abfragen schließlich auf einen SQL Server zurückgreift das nächste Zimmer.

In ähnlicher Weise, wenn Sie eine Anwendung der massiven Skala erstellen, und nach Skala meine ich, dass Millionen von Benutzern erwarten, ein paar Sekunden zwischen Aktionen warten, nicht Millionen von FX Trades eine Stunde, dann platzieren Sie eine Services-Schicht zwischen Ihrer Anwendung Die Daten sind ein allgemeines Muster. Die Skalierbarkeit des Internets basiert auf vielen kleinen zustandslosen HTTP-Servern und der Caching-Infrastruktur dazwischen.

Im echten Leben werden die gleichen Abfragen unzählige Male ausgeführt, die Leute aktualisieren Seiten oder klicken immer wieder auf denselben Link. Niemand fragt wirklich nach 10m Reihen, weil nicht viele Menschen es auf einmal sehen können.Das Arbeiten in kleinen Seiten hält die Daten fließend und fordert Interleaving an. Sie haben auch die Möglichkeit, einen Shared-in-RAM-Cache in der Services-Schicht oder sogar eine RAM-Datenbank einzuführen.

Sie können sogar feststellen, dass Sie Ihre Datenbank shard oder Partition zwischen SQL und einem Schlüssel/Wert speichern müssen. Sie können dann die Joins in der mittleren Schicht ausführen, skalieren und die verbindenden und rechenintensiven Materialien vom Datenbankserver entfernen.

Die Regel mit Internetskalierung ist, dass die Datenbank Ihr Hotspot ist und Sie alles tun müssen, um zu verhindern, dass jemand mit ihm spricht! Sei dieser lokale HTTP-Cache auf einem iPad, in Ihrem ISPs-Proxy, im IIS-Ausgabe-Cache oder in einem Redis-Cache, all diese Ebenen tragen dazu bei, die Last zu verteilen und die Last zu verringern.

Also, wenn Carl kam, um mit mir zu interviewen und erzählte mir, er hätte in Erwägung gezogen, eine OData-Schicht vor seine SQL-Boxen, würde ich seine Überlegungen zu hören.