it-swarm.com.de

Wie verwalte ich die technische Debatte über WCF vs. Web API?

Ich leite jetzt ein Team von etwa 15 Entwicklern, und wir stehen kurz vor der Auswahl der Technologie, bei der das Team in zwei völlig entgegengesetzte Teams aufgeteilt ist und über die Verwendung von WCF vs. Web-API debattiert.

Team A, das die Verwendung der Web-API unterstützt, bringt folgende Gründe vor:

  1. Die Web-API ist nur die moderne Art, Dienste zu schreiben ( Wikipedia )
  2. WCF ist ein Overhead für HTTP. Es ist eine Lösung für TCP, Net Pipes und andere Protokolle
  3. WCF-Modelle sind aufgrund von [DataContract] & [DataMember] und diesen Attributen kein POCO
  4. SOAP ist nicht so lesbar und praktisch wie JSON
  5. SOAP ist ein Overhead für das Netzwerk im Vergleich zu JSON (Transport über HTTP).
  6. Keine Methodenüberladung

Team B, das die Verwendung von WCF unterstützt, sagt:

  1. WCF unterstützt mehrere Protokolle (über Konfiguration)
  2. WCF unterstützt verteilte Transaktionen
  3. Für WCF gibt es viele gute Beispiele und Erfolgsgeschichten (während die Web-API noch jung ist).
  4. Duplex eignet sich hervorragend für die bidirektionale Kommunikation

Diese Debatte geht weiter und ich weiß nicht, was ich jetzt tun soll. Persönlich denke ich, dass wir ein Tool nur für den richtigen Verwendungsort verwenden sollten . Mit anderen Worten, wir sollten besser die Web-API verwenden, wenn wir einen Dienst über HTTP verfügbar machen möchten, aber WCF verwenden, wenn es um TCP und Duplex) geht.

Durch die Suche im Internet können wir kein solides Ergebnis erzielen. Es gibt viele Stellen zur Unterstützung von WCF, aber im Gegenteil, wir finden auch Leute, die sich darüber beschweren. Ich weiß, dass die Art dieser Frage fraglich klingt, aber wir brauchen einige gute Hinweise, um zu entscheiden. Wir stecken an einem Punkt fest, an dem die zufällige Auswahl einer Technologie dazu führen kann, dass wir es später bereuen. Wir wollen mit offenen Augen wählen.

Unsere Nutzung würde hauptsächlich für das Web erfolgen, und wir würden unsere Dienste über HTTP verfügbar machen. In einigen Fällen (z. B. 5 bis 10 Prozent) benötigen wir möglicherweise verteilte Transaktionen.

Was sollte ich jetzt tun? Wie gehe ich konstruktiv mit dieser Debatte um?

49
Saeed Neamati

Wenn beide Seiten gute Argumente haben und die Meinungen zu diesem Thema zu stark sind, um zu einem Konsens zu gelangen, müssen Sie als Manager eine Entscheidung treffen und die Debatte beenden. Andernfalls dreht es sich nur im Kreis und stärkt die Positionen aller Teilnehmer noch mehr. Je länger Sie warten, desto schwieriger wird es für die "Verliererseite", eine Niederlage zuzugeben und produktiv mit dem Ergebnis zu arbeiten.

Schreiben Sie alle Argumente auf, bewerten Sie ihre Bedeutung für das Projekt und treffen Sie dann Ihre Entscheidung. Wenn Sie nicht können, werfen Sie eine Münze. Ihr Projekt kann wahrscheinlich mit beiden Technologien erfolgreich abgeschlossen werden, und die Verschwendung wertvoller Zeit mit unnötigen Debatten kostet nur unnötiges Geld.

38
Philipp

Angenommen, beide Seiten sind in all ihren Argumenten zu 100% richtig. Welche sind wichtig?

WCF-Modelle sind aufgrund von [DataContract] & [DataMember] und diesen Attributen kein POCO

Kümmert es dich? Planen Sie etwas zu tun, das POCO erfordert?

WCF unterstützt verteilte Transaktionen

Ist dies wieder etwas, das Sie verwenden werden und das Sie bauen müssen, wenn Sie es nicht haben, weil Sie den anderen Weg eingeschlagen haben?

Grundsätzlich auf den Punkt kommen:

  • Bietet alles, was Sie brauchen (Wenn Sie nicht alles anbieten, was Sie brauchen, müssen Sie am wenigsten arbeiten).
  • Bietet die geringste Menge an Müll, die Sie nicht verbrauchen werden, die Sie aber trotzdem ertragen müssen.

Jedes Argument, das nicht auf dem Weg zu dem ist, was Sie erreichen müssen, ist irrelevant und sollte Ihre Entscheidung nicht berücksichtigen, mit einigem Spielraum für Überlegungen zur zukünftigen Expansion.

13
stonemetal

Gib meine zwei Cent rein.

Als Manager sollten Sie Ihre Teamkollegen bitten, das Yagni-Prinzip zu beachten. Dies wird dazu beitragen, die Liste der von beiden Teams vorgebrachten Gründe zu reduzieren.

Unsere Nutzung würde hauptsächlich für das Web erfolgen, und wir würden unsere Dienste über HTTP verfügbar machen. In einigen Fällen (z. B. 5 bis 10 Prozent) benötigen wir möglicherweise verteilte Transaktionen.

Anstatt in verteilte Transaktionen einzutauchen, sollten Sie stattdessen mit Kompensation arbeiten.

Als letztes ist die Lernkurve zu berücksichtigen. Abhängig von der Frist Ihres Projekts sollten Sie als Manager entscheiden können, ob es in Ordnung ist, mit dem Erlernen einer neuen Technologie zu beginnen oder nicht.

Wenn Sie viel Zeit verlieren, sollten Sie sich für eine Art Innovationstag entscheiden, an dem Team A und B einen Tag Zeit haben, um Beweise für Konzepte zu erstellen, die auf denselben Anforderungen basieren.

Übrigens, zu dem Typ, der sagt " WCF-Modelle sind aufgrund von [DataContract] & [DataMember] und diesen Attributen " kein POCO, sagen Sie es ihm dass POCOs im Allgemeinen als Domänenentitäten gedacht sind und dass es keine bewährte Methode ist, Ihr Domänenobjekt einer beliebigen Art von Clients auszusetzen. Dafür sind DTOs gedacht.

11
MaxSC

Was sollte ich jetzt tun? Wie gehe ich konstruktiv mit dieser Debatte um?

Halten Sie zuerst die Subjektivität fern. In den Argumenten Ihres WebAPI-Teams finde ich "Web-API ist nur der moderne Weg" *, "WCF-Modelle sind aufgrund dieser Attribute kein POCO" und "SOAP ist nicht so lesbar und praktisch wie JSON" ziemlich einfühlsam, wenn nicht einfach falsch, und hilft nicht, eine Entscheidung zu treffen.

Also, was zu tun ist: Entscheiden Sie, was Sie mit Ihren Diensten tun möchten , und wählen Sie dann eine Technik, die diesem Ziel und seiner Wartbarkeit und Erweiterbarkeit Rechnung trägt mit dem geringsten Schmerz. Sie können dies tun, indem Sie einfach untersuchen, ob ein bestimmter Aspekt vom zu verwendenden Framework unterstützt wird.

Interessantes Lesematerial:

*: Beachten Sie, dass Sie sich hierzu auf Wikipedia beziehen, wo das Zitat lautet: " Web 2.0-Webanwendungen haben sich von einer serviceorientierten entfernt Architektur (SOA) mit SOAP-basierten Webdiensten für eine zusammenhängendere Sammlung von RESTful-Webressourcen ". Dies ist ein Beispiel für die Verwendung, wenn Ihr Dienst von einer Webseite verwendet werden soll. Dies kann auch problemlos mit WCF mithilfe von WebHttpBinding durchgeführt werden. Es heißt nicht "WebAPI dafür verwenden".

Wenn diese Frage über das "Wie man die Diskussion verwaltet" hinausgeht: Ich würde WCF verwenden, wenn die Dienste von Nicht-Web-Clients genutzt werden sollen, da ihre Metadaten erstaunlich einfach stark sind. typisierte Client-Generierung.

5
CodeCaster

Unser Team hatte vor ein paar Monaten eine ähnliche Diskussion. Der entscheidende Faktor für uns war, wie wir jede Technologie erstellen und implementieren würden. Da wir bereits eine MVC-Anwendung erstellt und Knockout.js für die Datenbindung verwendet haben, haben wir MVVM effektiv verwendet, wobei die Controller lediglich eine API für Daten sind.

Dies ermöglichte es uns, unseren Einsatz der Technologien in diesem Projekt wie folgt zu kategorisieren:

  • Die Web-API wird als API für Knockout- und Ajax-Aufrufe verwendet und macht sie zu unseren Befehlen für das MVVM-Muster. Unsere Geschäftslogik für die Webanwendung ist hinter dieser Ebene durch eine Reihe von Klassen, Repositorys und Fabriken zusammengefasst.
  • WCF wird dann für unseren Datenspeicher verwendet und stellt Daten aus unserer Datenbank nicht nur für diese Website bereit, sondern auch für jede andere Website oder jeden anderen Dienst, der die offengelegten Daten verbraucht hat.

Obwohl dies möglicherweise keine beliebte oder hypertechnische Antwort ist, hat es meinem Team bei der Entscheidung, welche Technologie wo verwendet werden soll, geholfen, zu bestimmen, was Sie zuerst benötigen und wie oder ob die Technologie hilft.

4
Meshed

Abgesehen von der Teamverwaltung wählen Sie keine über die andere. Sie müssen sich den Zweck jedes Webdienstes ansehen und die entsprechende Technologie für den spezifischen Teil der Anwendung verwenden. Es ist wie das Verbot von Speicherprozeduren, wenn das Team das Entity Framework verwendet.

Unsere Nutzung würde hauptsächlich für das Web erfolgen, und wir würden unsere Dienste über HTTP verfügbar machen. In einigen Fällen (z. B. 5 bis 10 Prozent) benötigen wir möglicherweise verteilte Transaktionen.

Dann schreiben Sie diese 5 ~ 10% Webdienste in WCF. Wenn der Dienst in anderen Projekten intern referenziert werden soll, gibt es keine Debatte. Der Vorteil der Möglichkeit, einen WCF-Vertrag zum Erstellen des Client-Proxys zu importieren, steht NICHT zur Diskussion. Es bringt die gesamte Integration, Effizienz und Typensicherheit auf ein völlig neues Niveau.

Sie schreiben, was für öffentliche API- (vielleicht)/Ajax-Anfragen in Asp.net-Web-API verwendet werden soll.

Wenn es sich nur um einen seitenspezifischen Ajax-Aufruf handelt, können Sie einfach Asp.Net MVC verwenden.

Wähle nicht, umarme sie alle. Die Web-API von WCF und Asp.net dienen unterschiedlichen Zwecken. Niemand sagt, dass Sie nicht Apple und Orange beide in Ihrem Obstsalat haben können. Der Versuch, einen über den anderen zu pflücken und ihn in jedem einzelnen Szenario herunterzuschieben, ist einfach nur Faulheit.

4
Sleeper Smith

Mit anderen Worten, wir sollten besser die Web-API verwenden, wenn wir einen Dienst über HTTP verfügbar machen möchten, aber WCF verwenden, wenn es um TCP und Duplex) geht.

Das wäre der vernünftigste Ansatz. Es ist durchaus üblich, dass sowohl WCF- als auch WebApi-Dienste in derselben Webanwendung vorhanden sind, in der beide unterschiedlichen Zwecken dienen.

Nur um einige Argumente zu korrigieren:

WCF-Modelle sind aufgrund von [DataContract] & [DataMember] und diesen Attributen kein POCO

In vielen Fällen funktionieren WCF-Modelle ohne Datacontract/Datamember-Attribute.

SOAP ist nicht so lesbar und praktisch wie JSON

Es ist nicht wahr, aber WCF-Webdienste enthalten normalerweise einfaches XML anstelle von aufgeblähtem SOAP. Dies ist definitiv ist lesbar.

Ein Argument für WCF: Wenn eine WSDL verfügbar ist, gibt es in fast allen Technologien Unmengen von Tools, mit denen Proxys aus den Metadaten erstellt werden können. Andererseits wird das JSON-Schema noch nicht vollständig unterstützt.

3
Wiktor Zychla

Warum nicht mit WCF Data Services die Linie gehen? Schöne Abfragen im OData/Webapi-Stil und Benutzerfreundlichkeit mit den Fähigkeiten von WCF und der Fähigkeit, JSON zurückzugeben. Auch Wcf ist nicht so schlecht, wenn Sie einen schönen automatischen Wcf-Hosting-Code wie den folgenden haben:

https://github.com/ImaginaryDevelopment/MvcOdata

Ich würde sagen, dass sie überhaupt nicht weit voneinander entfernt sind, außer dass wir WebApi am Frontend und WCF data services auf der mittleren Ebene warf sich WebApi auf einfache Dinge wie String enthält oder String-Matching-Odata-Operatoren.

2
Maslow

Ein guter Architekt verzögert Technologieentscheidungen, bis sie unbedingt getroffen werden müssen.

Mit anderen Worten, treffen Sie die Entscheidung erst, wenn ein Client tatsächlich eine Verbindung herstellen muss. Sie können eine vollständig getestete Serviceschicht erstellen, ohne einen Transport-/Kommunikationsmechanismus darüber zu legen. 95% + der Arbeit können "unter" dem Adapter außerhalb des Frameworks ausgeführt werden.

Wenn Sie diese Dienste Remote-Clients zur Verfügung stellen möchten, können Sie das trendigste Framework von der Stange auswählen und dünne Wrapper über eine vielseitige Serviceschicht schreiben.

Zum Teufel, wenn Ihre "echte" Service-Schicht gut gemacht ist, können Sie sogar mehrere Wrapper mit minimalem Aufwand ausprobieren.

Das ist sowieso die dogmatische Antwort. In der Praxis möchten Sie vielleicht die Das einfachste Tool von der Stange, um frühe und häufige Integrationstests zu ermöglichen. Begrenzen Sie jedoch Ihre Abhängigkeit davon und behandeln Sie es streng als einfach dünne Kommunikationsschicht über den realen Diensten.


Wenn Sie diesen Ansatz wählen, werden Sie wahrscheinlich feststellen, dass Sie das einfachste Werkzeug auswählen, das anfangs verwendet werden soll , und niemand wird sich Sorgen machen , weil das Team weiß, dass sie es können Implementieren Sie später mit minimalem Aufwand ein komplexeres oder trendigeres Tool oder Framework , falls erforderlich .

1
svidgen

Daher stehe ich jetzt vor der gleichen Wahl. Ich habe mich gefragt, was die Teilmenge der Funktionen von WCF ist, die unser Team derzeit verwendet. Verwenden wir unterschiedliche Protokolle? Verwenden wir Transaktionsunterstützung? Nein (obwohl wir benutzerdefinierte Konsistenzmechanismen verwenden). Verwenden wir Duplex? Nein.

Warum möchten wir die Web-API verwenden? Einfachere Frontend-Integration (entfernt jetzt vorhandene zusätzliche Serviceschicht), SignalR zum Weiterleiten der Antwort an Clients und Zwischenspeichern für GETs.

Vielleicht könnte man andere Gründe finden :) Auch Gründe, bei WCF zu bleiben.

0
iiwaasnet

Ich würde fragen, welches Interaktionsmodell Sie unterstützen müssen. Entspricht Ihre gewünschte externe Schnittstelle eher RPC oder REST? Nach meiner Erfahrung ist es normalerweise irgendwo dazwischen, aber meistens das eine oder andere.

Verbrauchen Sie Ihre eigenen Dienste für andere Projekte in .Net? Dies ist wahrscheinlich die aufschlussreichste Frage, die Sie stellen können. WCF hat den Vorteil, dass Sie Ihre Schnittstellen in eine separate Klassenbibliothek abstrahieren und Ihren Client erstellen und einfügen können. Als Erweiterung dazu können Sie Ihr WCF-basiertes Projekt sowohl mit JSON- als auch mit SOAP/WSDL-Endpunkten bereitstellen. Ich habe es geschafft. WCF bietet auch bessere Sicherheiten für Ihre definierten Schnittstellen.

Das heißt, wenn Sie erwarten, dass Clients von anderen Plattformen XML im Allgemeinen haben, geschweige denn SOAP hat einen messbaren Overhead, der über die einfachen JSON-Endpunkte hinausgeht. Wenn Sie sich für die JSON/Web-API-Route entscheiden, dann Sie müssen viel besser dokumentieren können, wie Sie mit Ihren Endpunkten und Ihrer API interagieren.

Im Allgemeinen würde ich vorschlagen, ein einfaches API-Dokument zu schreiben, in dem angegeben ist, wie Sie Daten senden und wie Sie eine Antwort auf eine einzelne Anforderungsobjektstruktur wünschen. Schreiben Sie Ihren Testfall auf universellste Weise und dokumentieren Sie ihn als solchen. Ich würde eine einfache Curl-Anweisung empfehlen. Lassen Sie dies dann von mehreren Ihrer Mitglieder mithilfe von WCF und mit der Web-API implementieren. Dann sehen Sie, wer gewinnt.

Obwohl ich einige relativ große Projekte und Implementierungen mit WCF durchgeführt habe, neige ich tatsächlich zu der einfachsten Implementierung, die meiner Meinung nach eine reine WCF ist, bei der JSON-Ergebnisse und ein gewisses Überschreibungsverhalten in Global.asax.cs für den Umgang mit Fehlerbedingungen verwendet werden. Wenn die Dokumentation einer API Curl-Anweisungen enthält und Sie alle Funktionen Ihrer API mit Curl-Beispielen ausführen können, ist es für Clients viel einfacher, sie in einer beliebigen Sprache zu implementieren, die Webschnittstellen unterstützt. Hier beginnt die WCF wirklich zu fallen. Eine gut definierte API mit agnostischer Dokumentation ist besser als Strukturen mit automatisierten Werkzeugen im Umgang mit fremden Systemen. Sprechen als Verbraucher dieser Systeme von anderen Plattformen.

Eine Sache darüber hinaus ist die Implementierung Ihres Clients in zwei unterschiedlichen Sprachen. Führen Sie einen Client in C # aus, aber auch einen in Node.js oder Python) und sehen Sie, wie gut sie tatsächlich passen. Diese Übung allein hilft Ihnen dabei, die losen Enden in Ihrer API auszuräumen.

0
Tracker1

Wenn ich in Ihrer Position wäre, würde ich zunächst die Fähigkeiten Ihres Teams untersuchen. Wenn jeder in Ihrem Team WCF bereits kennt und nur ein kleiner Prozentsatz die Web-API kennt, ist Ihre Entscheidung bereits für Sie getroffen.

Wenn Sie Zeit haben, investieren Sie sie auf jeden Fall in das Lernen und die Verbesserung Ihrer Wissensbasis, jedoch nicht auf Kosten des Geschäftsbedarfs und der Unternehmensproduktivität.

0
user3333735