Auswahl der richtigen Technologie zum Erstellen der Serviceschicht in .NET

Beim Entwerfen der Service-Schicht in Ihren Anwendungen hängt die Wahl der Technologie, die in der Service-Schicht verwendet werden soll, von vielen Faktoren ab. In diesem Artikel werde ich eine Diskussion darüber präsentieren, wann und wie Sie sich für die Auswahl der richtigen Technologie zur Implementierung der Service-Schicht beim Entwerfen von Anwendungen in .Net entscheiden können.

Zwei wichtige Konkurrenten beim Entwerfen der Serviceschicht in .Net sind WCF und Web-API. WCF ist eine Entwicklungsplattform für SOA - es bietet viele Funktionen und unterstützt viele verschiedene Transportprotokolle. Während WCF ein einheitliches Framework zum Erstellen serviceorientierter Anwendungen ist, ist die Web-API eine einfache Alternative zum Erstellen von RESTful-Services, die von vielen verschiedenen Clients verwendet werden können. RESTful-Services verwenden einfaches HTTP und sind einfach mit viel weniger Nutzlast im Vergleich zu SOAP-Services. Sie können die WebHttpBinding in WCF verwenden, um RESTful-Dienste ohne SOAP über HTTP zu erstellen. WCF ist viel vielseitiger in dem Sinne, dass es viele Transportprotokolle unterstützen kann - HTTP, TCP usw. Sie können WCF nutzen, um sichere, zuverlässige und Transaktionsdienste aufzubauen, die Messaging, Duplexkommunikation und schnelle Transportkanäle wie TCP unterstützen ,Named Pipes oder UDP.

Wenn Sie über HTTP einfache, ressourcenorientierte Dienste erstellen müssen, die alle Funktionen des HTTP-Protokolls nutzen, die Versionierung, die Cache-Steuerung für Browser und die Parallelität mit Etags verwenden können, ist die Web-API eine gute Wahl. Sie sollten in Ihrer Service-Schicht die Web-API gegenüber der WCF wählen, wenn Sie Ihre Services einer breiten Palette von Clients aussetzen möchten, z. B. Webbrowsern, Handys, Tablets usw. Die Web-API ist leicht und eignet sich gut für Geräte mit eingeschränkten Funktionen Bandbreite wie Smartphones. Eine der Hauptbeschränkungen bei der Verwendung von WCF ist die umfangreiche Konfiguration. Die Web-API ist viel einfacher und benutzerfreundlicher. Ich gebe zu, dass WCF im Vergleich zur Web-API viel vielseitiger ist, aber wenn Sie die von WCF bereitgestellten Funktionen nicht benötigen und nur RESTful-Dienste über HTTP benötigen,Ich würde immer die Web-API bevorzugen, da sie leicht und einfach zu bedienen ist.

Ich möchte auch eine Diskussion über die Unterschiede zwischen Web-API und ASP.Net MVC präsentieren, da es bestimmte Missverständnisse darüber gibt, wann eine über die andere gewählt werden soll. Die Wahl zwischen ASP.Net MVC und Web API hängt von vielen Faktoren ab. Es gibt bestimmte Überlegungen, die Sie berücksichtigen müssen, bevor Sie sich für eine dieser Überlegungen entscheiden.

Beachten Sie, dass die Web-API HTTP-Verben und damit eine auf HTTP-Verben basierende Zuordnung verwendet, um Methoden den jeweiligen Routen zuzuordnen. Sie können keine Methoden für dasselbe HTTP-Verb für eine bestimmte Route überladen haben. Sie sollten sich dieser Entwurfsbeschränkung bewusst sein (obwohl Problemumgehungen verfügbar sind), wenn Sie zwischen ASP.Net MVC und Web-API wählen. Im Gegensatz zu ASP.Net MVC verwendet die Web-API Routing basierend auf HTTP-Verben anstelle von URIs, die Aktionen enthalten. Sie können also die Web-API verwenden, um RESTful-Services zu schreiben, die das HTTP-Protokoll nutzen können. Sie können Services entwerfen, die einfacher zu testen und zu warten sind. Das Routing in der Web-API ist viel einfacher und Sie können die Inhaltsverhandlung nahtlos nutzen. Das Routing-Modell in ASP.Net MVC enthält Aktionen in den URIs.

Ein weiterer Punkt, den Sie berücksichtigen möchten, ist, ob Ihre Funktionalität für eine bestimmte Anwendung verfügbar gemacht werden soll oder ob die Funktionalität generisch sein soll. Wenn Sie Ihre Dienste nur für eine Anwendung verfügbar machen möchten, möchten Sie ASP.Net MVC verwenden. Der Controller in einer ASP.Net MVC-Anwendung ist anwendungsspezifisch. Im Gegenteil, Sie möchten einen Web-API-Ansatz, wenn Ihre geschäftlichen Anforderungen erfordern, dass Sie die Funktionalität generisch verfügbar machen. Ich würde es vorziehen, den Web-API-Ansatz zu verwenden, wenn die Funktionalität datenzentrierter ist, und den ASP.Net MVC-Ansatz, wenn die Funktionalität mehr auf die Benutzeroberfläche ausgerichtet ist.

Sie sollten die Web-API über ASP.Net MVC verwenden, wenn Ihr Controller Daten in verschiedenen Formaten wie JSON, XML usw. zurückgeben soll. Außerdem ist die Angabe des Datenformats in der Web-API einfach und leicht zu konfigurieren. Die Web-API punktet auch gegenüber ASP.Net MVC hinsichtlich ihrer Fähigkeit, selbst gehostet zu werden (ähnlich wie WCF). Sie müssten ASP.Net MVC-Controller auf demselben Webserver hosten, auf dem die Anwendung gehostet wurde, da die ASP.Net MVC-Controller Teil derselben Anwendung sind. Im Gegenteil, Sie können Ihre Web-API-Controller auch außerhalb von IIS hosten. Sie können sie auf einem kompakten benutzerdefinierten Host hosten und zulassen, dass der Dienst von vielen verschiedenen Clients genutzt wird.