Når du designer tjenestelaget i applikasjonene dine, avhenger valget av teknologien som skal brukes i tjenestelaget av mange faktorer. I denne artikkelen vil jeg presentere en diskusjon om når og hvordan du kan bestemme deg for å velge riktig teknologi for å implementere tjenestelaget når du designer applikasjoner i .Net.
To fremtredende utfordrere du har når du designer tjenestelaget i .Net er WCF og Web API. WCF er en utviklingsplattform for SOA - den har mange funksjoner og støtter mange forskjellige transportprotokoller. Mens WCF er et samlet rammeverk for å bygge tjenesteorienterte applikasjoner, er Web API et lett alternativ for å bygge RESTful-tjenester som kan konsumeres av mange forskjellige klienter. RESTful-tjenester bruker grunnleggende HTTP og er enkle med mye mindre nyttelast sammenlignet med SOAP-tjenester. Du kan bruke WebHttpBinding i WCF til å bygge tjenester som ikke er SOAP RESTful over HTTP. WCF er mye mer allsidig i den forstand at den kan støtte mange transportprotokoller - HTTP, TCP, etc. Du kan utnytte WCF til å bygge sikre, pålitelige og transaksjonelle tjenester som kan støtte meldinger, tosidig kommunikasjon og raske transportkanaler som TCP , Named Pipes eller UDP.
Hvis du trenger å bygge lette, ressursorienterte tjenester over HTTP som kan utnytte alle funksjonene i HTTP-protokollen, bruke versjonering, cache-kontroll for nettlesere og samtidighet ved hjelp av Etags, er Web API et godt valg. Du bør velge Web API over WCF i tjenestelaget ditt når du ønsker å eksponere tjenestene dine for et bredt spekter av klienter, dvs. nettlesere, mobiltelefoner, nettbrett, etc. Web API er lett og passer godt på enheter som har begrenset båndbredde som smarttelefoner. En av de største begrensningene jeg møtte mens jeg brukte WCF, er den omfattende konfigurasjonen - Web API er mye enklere og enkel å bruke. Jeg innrømmer at WCF er mye mer allsidig sammenlignet med Web API, men hvis du ikke trenger funksjonene som WCF tilbyr, og alt du trenger er bare RESTful-tjenester over HTTP, vil jeg alltid foretrekke Web API, siden det er lett og enkelt å bruke .
Jeg vil også presentere en diskusjon om forskjellene mellom Web API og ASP.Net MVC, da det er visse misforståelser om når man skal velge hverandre. Valget mellom ASP.Net MVC og Web API avhenger av mange faktorer. Det er visse hensyn du må huske på før du bestemmer deg for å bruke en av dem.
Merk at Web API bruker HTTP-verb og dermed HTTP-verbbasert kartlegging for kartleggingsmetoder til respektive ruter. Du kan ikke ha overbelastede metoder for det samme HTTP-verbet for en bestemt rute. Du bør være oppmerksom på denne begrensningen i utformingen (selv om løsninger er tilgjengelige) når du velger mellom ASP.Net MVC og Web API. I motsetning til ASP.Net MVC bruker Web API ruting basert på HTTP-verb i stedet for URI-er som inneholder handlinger. Så du kan bruke Web API til å skrive RESTful-tjenester som kan utnytte HTTP-protokollen - du kan designe tjenester som er lettere å teste og vedlikeholde. Ruting i Web API er mye enklere, og du kan utnytte innholdsforhandlinger sømløst. Rutemodellen i ASP.Net MVC inkluderer handlinger i URI-ene.
Et annet poeng du vil vurdere er om du vil at funksjonaliteten din skal eksponeres for et bestemt program, eller om funksjonaliteten skal være generisk. Hvis du bare vil eksponere tjenestene dine spesifikt for ett program, vil du bruke ASP.Net MVC - kontrolleren i et ASP.Net MVC-program er applikasjonsspesifikk. Tvert imot, du vil ha en Web API-tilnærming hvis bedriftens behov krever at du eksponerer funksjonaliteten generelt. Jeg foretrekker å bruke Web API-tilnærmingen hvis funksjonaliteten er mer datasentrisk og ASP.Net MVC-tilnærmingen hvis funksjonaliteten er mer UI-sentrert.
Du bør bruke Web API over ASP.Net MVC hvis du vil at kontrolleren din skal returnere data i flere formater som JSON, XML, etc. Det er også enkelt og enkelt å konfigurere å spesifisere dataformatet i Web API. Web API scorer også over ASP.Net MVC i sin evne til å være selvhusholdende (ligner på WCF). Du trenger ASP.Net MVC-kontrollere for å være vert i den samme webserveren der applikasjonen er vert fordi ASP.Net MVC-kontrollere er en del av samme applikasjon. Tvert imot, du kan også være vert for Web API-kontrollere utenfor IIS - du kan være vert for den i en lett tilpasset vert og la tjenesten konsumeres av mange forskjellige klienter.
