Når du designer servicelaget i dine applikationer, afhænger valget af den teknologi, der skal bruges i servicelaget, af mange faktorer. I denne artikel vil jeg præsentere en diskussion om hvornår og hvordan du kan beslutte at vælge den rigtige teknologi til implementering af servicelaget, når du designer applikationer i .Net.
To fremtrædende kandidater, du har, når du designer servicelaget i .Net, er WCF og Web API. WCF er en udviklingsplatform for SOA - den giver mange funktioner og understøtter mange forskellige transportprotokoller. Mens WCF er en samlet ramme til opbygning af serviceorienterede applikationer, er Web API et letvægtsalternativ til at opbygge RESTful-tjenester, der kan forbruges af mange forskellige klienter. RESTful-tjenester bruger grundlæggende HTTP og er enkle med meget mindre nyttelast sammenlignet med SOAP-tjenester. Du kan bruge WebHttpBinding i WCF til at opbygge ikke-SOAP RESTful-tjenester via HTTP. WCF er meget mere alsidig i den forstand, at den kan understøtte mange transportprotokoller - HTTP, TCP osv. Du kan udnytte WCF til at opbygge sikre, pålidelige og transaktionelle tjenester, der kan understøtte messaging, duplexkommunikation og hurtige transportkanaler som TCP , Navngivne rør eller UDP.
Hvis du har brug for at opbygge lette, ressourceorienterede tjenester via HTTP, der kan udnytte de fulde funktioner i HTTP-protokollen, bruge versionering, cache-kontrol til browsere og samtidighed ved hjælp af Etags, er Web API et godt valg. Du skal vælge Web API over WCF i dit servicelag, når du ønsker at udsætte dine tjenester for en bred vifte af klienter, dvs. webbrowsere, mobiltelefoner, tablets osv. Web API er let og er velegnet på enheder, der har begrænset båndbredde som smartphones. En af de største begrænsninger, jeg stod overfor under brug af WCF, er dens omfattende konfiguration - Web API er meget enklere og nem at bruge. Jeg indrømmer, at WCF er meget mere alsidig sammenlignet med Web API, men hvis du ikke har brug for de funktioner, WCF leverer, og alt hvad du behøver, er bare RESTfulde tjenester over HTTP, foretrækker jeg altid Web API, da det er let og nemt at bruge .
Jeg vil også gerne præsentere en diskussion om forskellene mellem Web API og ASP.Net MVC, da der er visse misforståelser om, hvornår man skal vælge den ene frem for den anden. Valget mellem ASP.Net MVC og Web API afhænger af mange faktorer. Der er visse overvejelser, du bliver nødt til at huske på, før du beslutter dig for at bruge en af dem.
Bemærk, at Web API bruger HTTP-verber og dermed HTTP-verbbaseret kortlægning til kortlægningsmetoder til respektive ruter. Du kan ikke have overbelastede metoder til det samme HTTP-verb for en bestemt rute. Du skal være opmærksom på denne designbegrænsning (selvom løsninger er tilgængelige), når du vælger mellem ASP.Net MVC og Web API. I modsætning til ASP.Net MVC bruger Web API routing baseret på HTTP-verber snarere end URI'er, der indeholder handlinger. Så du kan bruge Web API til at skrive RESTful-tjenester, der kan udnytte HTTP-protokollen - du kan designe tjenester, der er lettere at teste og vedligeholde. Routing i Web API er meget enklere, og du kan udnytte indholdsforhandling problemfrit. Rutemodellen i ASP.Net MVC inkluderer handlinger i URI'erne.
Et andet punkt, du vil overveje, er, om du vil have din funktionalitet til at blive eksponeret for en bestemt applikation, eller om funktionaliteten skal være generisk. Hvis du kun vil eksponere dine tjenester, der er specifikke for en applikation, vil du bruge ASP.Net MVC - controlleren i et ASP.Net MVC-program er applikationsspecifik. Tværtimod vil du have en Web API-tilgang, hvis din virksomheds behov kræver, at du udsætter funktionaliteten generelt. Jeg foretrækker at bruge Web API-tilgangen, hvis funktionaliteten er mere datacentreret og ASP.Net MVC-tilgangen, hvis funktionaliteten er mere UI-centreret.
Du bør bruge Web API over ASP.Net MVC, hvis du vil have, at din controller skal returnere data i flere formater som JSON, XML osv. Det er også nemt og nemt at konfigurere at specificere dataformatet i Web API. Web API scorer også over ASP.Net MVC i sin evne til at være selvhostet (svarende til WCF). Du skal bruge ASP.Net MVC-controllere til at være hostet i den samme webserver, hvor applikationen er hostet, fordi ASP.Net MVC-controllerne er en del af den samme applikation. Tværtimod kan du også være vært for dine web-API-controllere uden for IIS - du kan være vært for den i en let tilpasset vært og tillade, at tjenesten forbruges af mange forskellige klienter.
