Ich leite derzeit ein Team von etwa 15 Entwicklern und wir stecken an einem Punkt der Auswahl der Technologie fest, an dem 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, führt folgende Gründe an:
- Web-API ist nur die moderne Art, Dienste zu schreiben ( Wikipedia )
- WCF ist ein Overhead für HTTP. Es ist eine Lösung für TCP, Net Pipes und andere Protokolle
- WCF-Modelle sind aufgrund von [DataContract] & [DataMember] und diesen Attributen nicht POCO
- SOAP ist nicht so lesbar und handlich wie JSON
- SOAP ist ein Overhead für das Netzwerk im Vergleich zu JSON (Transport über HTTP)
- Keine Methodenüberladung
Team B, das die Verwendung von WCF unterstützt, sagt:
- WCF unterstützt mehrere Protokolle (über Konfiguration)
- WCF unterstützt verteilte Transaktionen
- Es gibt viele gute Beispiele und Erfolgsgeschichten für WCF (während die Web-API noch jung ist)
- 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 Einsatzort verwenden sollten . Mit anderen Worten, wir sollten besser die Web-API verwenden, wenn wir einen Dienst über HTTP verfügbar machen möchten, aber wenn es um TCP und Duplex geht, sollten wir WCF verwenden.
Wenn wir im Internet suchen, können wir kein solides Ergebnis erzielen. Es gibt viele Stellen für die Unterstützung von WCF, aber im Gegenteil, wir finden auch Leute, die sich darüber beschweren. Ich weiß, dass die Art dieser Frage vielleicht fraglich klingt, aber wir brauchen einige gute Hinweise, um uns zu entscheiden. Wir stecken an einem Punkt fest, an dem wir es möglicherweise später bereuen, wenn wir uns zufällig für eine Technologie entscheiden . 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 (etwa 5 bis 10 Prozent) benötigen wir jedoch möglicherweise verteilte Transaktionen.
Was sollte ich jetzt tun? Wie gehe ich konstruktiv mit dieser Debatte um?
Antworten:
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", sich geschlagen zu geben und produktiv mit dem Ergebnis zu arbeiten.
Notieren Sie sich alle Argumente, bewerten Sie deren 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.
quelle
Angenommen, beide Seiten haben in all ihren Argumenten 100% Recht. Welche sind von Bedeutung?
Kümmert es dich? Planen Sie etwas zu tun, das POCO erfordert?
Wieder ist dies etwas, das Sie verwenden und bauen müssen, wenn Sie es nicht haben, weil Sie den anderen Weg eingeschlagen haben?
Grundsätzlich geht es darum, worauf es ankommt:
Alle Argumente, die nicht auf dem Weg sind, was Sie erreichen müssen, sind irrelevant und sollten Ihre Entscheidung nicht berücksichtigen.
quelle
Steck 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.
Anstatt sich auf verteilte Transaktionen einzulassen, sollten Sie stattdessen die Vergütung in Betracht ziehen .
Als letztes muss die Lernkurve berücksichtigt werden. Abhängig von der Frist Ihres Projekts sollten Sie als Manager entscheiden können, ob es in Ordnung ist, eine neue Technologie zu erlernen oder nicht.
Wenn Sie viel Zeit zum Verschwenden haben, sollten Sie sich auf einen Innovationstag einlassen, an dem Team A und B einen Tag Zeit haben, um Konzepte auf der Grundlage derselben Anforderungen nachzuweisen.
Übrigens, sagen Sie dem Typen, der sagt, " WCF-Modelle sind aufgrund von [DataContract] & [DataMember] und diesen Attributen keine POCOs", dass POCOs im Allgemeinen als Domain-Entitäten gedacht sind und dass es keine bewährte Methode ist, sie offenzulegen Ihre Domain Objekt für jede Art von Kunden, das ist, wofür DTOs sind.
quelle
Halten Sie zunächst die Subjektivität fern. In Ihren Argumenten des WebAPI Teams, finde ich „Web - API nur der moderne Weg ist , “ * „WCF - Modelle nicht POCO sind, weil diese Attribute“ und „SOAP ist nicht so lesbar und handlich wie JSON“ ziemlich eigenwillig, wenn nicht nur falsch , und wird nicht helfen, 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 aus, die diesem Ziel und seiner Wartbarkeit und Erweiterbarkeit mit dem geringsten Aufwand gerecht wird. Sie können dies tun, indem Sie einfach untersuchen, ob ein bestimmter Aspekt von dem zu verwendenden Framework unterstützt wird.
Interessantes Lesematerial:
* Hinweis: Sie hierfür auf Wikipedia verweisen, wo das Zitat ist: „ Web 2.0 Web - Anwendungen haben bewegt von einer serviceorientierten Architektur (SOA) mit SOAP-basierten Web - Service zu mehr Zusammenhalt Sammlungen von RESTful Web - Ressourcen weg“ . Dies ist ein Beispiel für die Verwendung, wenn Ihr Service von einer Webseite aus genutzt werden soll. Dies kann auch problemlos mit WCF mithilfe von WebHttpBinding durchgeführt werden. Es heißt nicht "Verwenden Sie WebAPI für diese" .
Wenn diese Frage über das "Verwalten der Diskussion" hinausgeht : Ich würde WCF verwenden, wenn die Dienste von Nicht-Web-Clients genutzt werden sollen, da ihre Metadaten eine erstaunlich einfache, stark typisierte Client-Generierung ermöglichen.
quelle
Abgesehen von der Teamleitung wählen Sie nicht eine über die andere. Sie müssen den Zweck jedes Webdienstes untersuchen und die entsprechende Technologie für den spezifischen Teil der Anwendung verwenden. Es ist wie das Verbot von Geschäftsvorgängen, wenn das Team das Entity-Framework verwendet.
Dann schreiben Sie diese 5 ~ 10% Webservices in WCF. Wenn der Service 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 (möglicherweise) / Ajax-Anforderungen in der Asp.net-Web-API verwendet werden soll.
Wenn es sich nur um einen seitenbezogenen Ajax-Aufruf handelt, können Sie einfach Asp.Net MVC verwenden.
Wähle nicht, umarme sie alle. WCF und Asp.net Web API dienen unterschiedlichen Zwecken. Niemand sagt, Sie können weder Apfel noch Orange in Ihrem Obstsalat haben. Der Versuch, eines über das andere zu heben und jedes einzelne Szenario herunterzuschieben, ist einfach nur Faulheit.
quelle
Unser Team hatte vor ein paar Monaten eine ähnliche Diskussion. Der entscheidende Faktor für uns war, wie wir jede Technologie entwickeln und implementieren. Da wir bereits eine MVC-Anwendung erstellt und Knockout.js für die Datenbindung verwendet haben, haben wir MVVM effektiv verwendet, wobei die Controller nur eine API für Daten sind.
Dies ermöglichte uns, unseren Einsatz der Technologien bei diesem Projekt wie folgt zu kategorisieren:
Dies ist möglicherweise keine beliebte oder hypertechnische Antwort. Die Entscheidung darüber, was Sie zuerst benötigen und wie oder ob die Technologie hilfreich ist, hat meinem Team geholfen, zu entscheiden, welche Technologie wo eingesetzt werden soll.
quelle
Das wäre der vernünftigste Ansatz. Es ist durchaus üblich, dass sowohl WCF- als auch WebApi-Dienste in derselben Webanwendung vorhanden sind und beide unterschiedliche Zwecke erfüllen.
Nur um ein paar Argumente zu korrigieren:
In vielen Fällen funktionieren WCF-Modelle ohne Datenvertrags- / Datenelementattribute.
Es ist nicht wahr, aber WCF-Webdienste enthalten normalerweise einfaches XML und kein aufgeblähtes SOAP. Dies ist definitiv ist lesbar.
Ein Argument für WCF: Wenn eine WSDL verfügbar ist, gibt es Unmengen von Tools in fast allen Technologien, die Proxys aus den Metadaten erstellen können. Andererseits wird das JSON-Schema noch nicht überall unterstützt.
quelle
Warum gehen Sie nicht mit WCF Data Services die Linie? nette Abfragen im OData / Webapi-Stil und Benutzerfreundlichkeit mit den Kräften von WCF und der Fähigkeit, einwandfrei zurückzukehren
JSON. Auch Wcf ist nicht so schlimm, wenn Sie einen netten automatischen Wcf-Hosting-Code wie den folgenden haben:https://github.com/ImaginaryDevelopment/MvcOdata
Ich würde sagen, sie sind überhaupt nicht weit voneinander entfernt, außer dass wir uns bei der Verwendung
WebApiim Front-End undWCF data servicesin der mittleren EbeneWebApimit einfachen Dingen wie String-Enthalten oder String-Matching-Odata-Operatoren befasst haben.quelle
Ein guter Architekt verzögert Technologieentscheidungen, bis sie absolut notwendig sind.
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. Über 95% der Arbeiten können "unterhalb" des Adapters außerhalb des Frameworks ausgeführt werden.
Wenn Sie diese Dienste für Remoteclients verfügbar machen möchten, können Sie das trendigste Framework von der Stange auswählen und Thin Wrapper über eine vielseitige Serviceebene schreiben.
Zur Hölle, wenn Ihre "echte" Service-Schicht gut gemacht ist, können Sie sogar mehrere Wrapper mit minimalem Aufwand ausprobieren.
Das ist jedenfalls die dogmatische Antwort. In der Praxis möchten Sie möglicherweise das einfachste Tool von der Stange nehmen, um frühzeitige und häufige Integrationstests zu ermöglichen. Beschränken Sie jedoch Ihre Abhängigkeit und behandeln Sie es strikt als eine einfache Kommunikationsschicht über den tatsächlichen Diensten.
Wenn Sie diesen Ansatz wählen, werden Sie wahrscheinlich feststellen, dass Sie das am einfachsten zu verwendende Tool auswählen, und niemand wird Probleme damit haben , da das Team weiß, dass es später ein ausgefeilteres oder trendigeres Tool oder Framework bei Bedarf mit minimalem Aufwand implementieren kann.
quelle
Daher stehe ich jetzt vor der gleichen Wahl. Ich habe mich gefragt, welche Teilmenge der Funktionen von WCF unser Team derzeit verwendet. Verwenden wir unterschiedliche Protokolle? Nein. Nutzen wir die Transaktionsunterstützung? Nein (obwohl wir benutzerdefinierte Konsistenzmechanismen verwenden). Verwenden wir Duplex? Nein.
Warum möchten wir die Web-API verwenden? Einfachere Frontend-Integration (entfernt zusätzliche Service-Schicht), SignalR für Push-Antworten an Clients, Caching für GETs.
Vielleicht könnte man andere Gründe finden :) Auch Gründe, bei WCF zu bleiben.
quelle
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 geringer Prozentsatz die Web-API kennt, ist Ihre Entscheidung bereits für Sie getroffen.
Wenn Sie die Zeit haben, investieren Sie sie auf jeden Fall in das Lernen und die Verbesserung Ihrer Wissensbasis, jedoch nicht auf Kosten der geschäftlichen Anforderungen und der Produktivität des Unternehmens.
quelle
Ich würde fragen, welches Interaktionsmodell Sie unterstützen müssen. Entspricht Ihre gewünschte externe Schnittstelle eher RPC oder REST? Nach meiner Erfahrung liegt es normalerweise irgendwo dazwischen, aber meistens zwischen dem einen und dem anderen.
Konsumieren Sie Ihre eigenen Dienste für andere Projekte in .Net? Dies ist wahrscheinlich die aufschlussreichste Frage, die Sie stellen können. WCF bietet den Vorteil, dass Sie Ihre Schnittstellen in eine separate Klassenbibliothek abstrahieren und Ihren Client erstellen und einbinden können. Als Erweiterung dazu können Sie Ihr WCF-basiertes Projekt sowohl mit JSON- als auch mit SOAP / WSDL-Endpunkten bereitstellen. WCF bietet auch bessere Sicherheiten gegenüber Ihren definierten Schnittstellen.
Wenn Sie jedoch generell erwarten, dass Clients von anderen XML-Plattformen stammen, hat SOAP einen messbaren Overhead, der über die einfachen JSON-Endpunkte hinausgeht. Wenn Sie sich für die JSON / Web-API entscheiden, müssen Sie besser dokumentieren, wie Sie mit Ihren Endpunkten und der API interagieren.
Im Allgemeinen würde ich vorschlagen, ein einfaches API-Dokument zu schreiben, in dem angegeben ist, wie Sie Daten übermitteln und wie Sie auf eine einzelne Anforderungsobjektstruktur antworten möchten. Schreiben Sie Ihren Testfall so universell wie möglich und dokumentieren Sie ihn als solchen. Ich würde eine einfache Locke Aussage empfehlen. Lassen Sie dann mehrere Ihrer Mitglieder dies mithilfe von WCF und der Web-API implementieren. Dann sehen Sie, welche gewinnt.
Persönlich neige ich, obwohl ich einige relativ große Projekte und Implementierungen mit WCF durchgeführt habe, zur einfachsten Implementierung, die meines Erachtens in der Verwendung von JSON-Ergebnissen und einem gewissen Überschreibungsverhalten in Global.asax.cs für den Umgang mit Fehlerbedingungen liegt. Wenn die Dokumentation einer API curl-Anweisungen enthält und Sie die gesamte Funktionalität Ihrer API mit curl-Beispielen ausüben können, können Clients viel einfacher in jeder Sprache implementiert werden, die Webschnittstellen unterstützt. Dies ist wirklich, wo WCF beginnt zu fallen. Eine gut definierte API mit agnostischer Dokumentation ist besser als Strukturen mit automatisierten Werkzeugen im Umgang mit fremden Systemen. Als Verbraucher dieser Systeme von anderen Plattformen sprechen.
Darüber hinaus können Sie Ihren Client in zwei verschiedenen Sprachen implementieren. Machen Sie einen Client in C #, aber machen Sie auch einen in Node.js oder Python und sehen Sie, wie gut sie tatsächlich passen. Diese Übung allein wird Ihnen helfen, die losen Enden in Ihrer API auszuräumen.
quelle