MVC vs. Web API: Hvilken ASP.NET-teknologi skal du bruge?
I denne artikel vil vi tale om forskellene mellem ASP.NET Model View Controller (MVC) og ASP.NET Web API, og som du skal bruge til forskellige krav. Før vi går dybere, lad os få en kort introduktion til, hvad MVC faktisk er.
MVC eller Model-View-Controller er det, der faktisk deler en applikation.
- Model – Dette er objekter, der henter modeltilstanden i databasen, dvs. den henter dataene fra databasen, udfører en bestemt handling og gemmer dataene i databasen.
- Udsigt – Her kan udviklerne ‘se’ brugergrænsefladen eller brugergrænsefladen for de applikationer, der er oprettet ved datamodel.
- Controllere – Controllere eller komponenter styrer brugerinteraktionen, administrerer forespørgselsstrengværdierne og overfører værdierne til modeller.
Du finder MVC i samlingen “System.Web.MVC”. MVC-rammen bruger ASP.NET-funktionerne som medlemskabsbaseret godkendelse, mastersider osv. Du kan prøve de forskellige muligheder i ASP.NET til oprettelse af webapplikationer med ASP.NET webformularer.
Via ASP.NET Web API kan du vise former for data som XML og JSON. Denne ramme er open source, bruger HTTP-service, og det er et stykke kage at svare på klientanmodninger. Selve anmodningerne (f.eks. Get, Post, Delete, Put osv.) Administreres ved hjælp af HTTP-protokoller. ASP.NET Web API kan hostes på IIS eller i applikationen.
Begyndere bliver normalt forvirrede over valget af ASPNET-teknologi, der skal bruges. Her er et par tilfælde, hvor du kan bruge hver af disse teknologier.
1) Processen med at eksponere funktionalitet
ASP.NET MVC-controllere ville være et godt valg (1) hvis du ønsker at eksponere en funktionalitet i en enkelt applikation eller (2) hvis den skal bruges som en generisk funktionalitet i ethvert program. Du kan spare tid på denne måde, fordi du ikke behøver at oprette en ny API for at eksponere funktionalitet hver gang. Normalt er en controller knyttet til en bestemt webapplikation, og den udsætter funktionaliteter, der hurtigt skal forbruges gennem Ajax.
Hvis du ønsker at oprette en fuldgyldig REST-tjeneste, der ikke er knyttet til en enkelt applikation, kan du bruge Web API, fordi den leverer en elegant og pæn løsning.
Hvis funktionaliteten er UI eller View-centreret, f.eks. Indlæsning af HTML-fragmenter eller oprettelse af AJAX-drevne sider, er ASP.NET MVC et bedre valg. Web API ville være et godt valg, når du opretter en uafhængig RESTful service.
Hvis funktionaliteten er data-centreret, skal du vælge Web API-servere. Eksempel på CRUD-operationer. I normale MVC-applikationer er bare controllerne tilstrækkelige til at returnere både data og visninger.
2) De dataformater, der skal håndteres
Controllere returnerer enten ActionResult eller JsonResult, hvilket betyder, at controllerens output kan være enten HTML-markering eller JSON-formaterede data. Hvis et af disse dataformater er nok, kan du bruge handlingsmetoder til at udsætte funktionaliteter. Men når flere dataformater er involveret, ville Web API være det bedre valg. Dette skyldes, at denne teknologi automatisk kan bestemme webformatet ved at se på Accepter overskrift. I MVC-controlleren skal du specifikt specificere dataformatet for at skrive handlingsmetoder.
Web API kan bruges til at generere HTTP-tjenester, der svarer data alene, men MVC vil være egnet til at udvikle webapplikationer, der svarer som både, visninger og data.
Web API ser på Accepter overskrift på anmodningen, der returnerer dataene i forskellige formater, så den kan returnere i forskellige formater, som XML, JSON osv. Men for MVC er de returnerede data kun i JSON-format ved hjælp af JSONResult.
3) Når du kombinerer MVC og Web API
Udviklere kan nyde et par fordele, når de kombinerer både MVC-controller og API.
(1) Du kan administrere AJAX-anmodningerne og returnere svaret i flere formater, når du kombinerer begge.
(2) Du kan oprette to forskellige filtre til godkendelse af et program. Anmodningerne kortlægges til handlingerne på HTTP-verber, men det kortlægges til handlingsnavnet i MVC. Du kan bruge API som et enkeltstående servicelag, og det kan også bruges med ASP.NET.
Modelbinding, routing, filtre er alle forskellige i Web API og eksisterer i System.web.http-samlingen. Disse funktioner findes i System.web.MVC i MVC-rammen.
4) Uanset om du har brug for egenhosting
Som du ved, behøver controller, en del af ASP.NET MVC-applikationerne IIS som værtsmiljø. API er dog en servicestel, og du kan selv være vært for det. Dette gør det let, fordi du kan undgå omkostningerne ved IIS. Dette er et godt valg, når din app skal frigives på en række platforme – desktop, webapplikationer, konsolapplikationer osv.
Afsluttende tanker
Du kan vælge Web API, hvis du genererer en fuldt blæst HTTP-tjeneste som Flickr, Amazon, Delicious osv. Det er også et godt valg, hvis du har brug for indholdsforhandling. Indholdsforhandling er en proces med returnering af indhold i et format nævnt af Accept Header. Du har dog muligvis ikke brug for det til alle dine projekter, fordi afsendelse af data som JSON og XML hovedsagelig er det, der kræves. Med Web API har du mulighed for at sende indholdet i en række forskellige formater, inklusive billeder og filer.
WebAPI er måske en bedre ramme, når du vil udstille dine data og tjenester til forskellige enheder. Og det er open source, og dermed den perfekte platform til at skabe RESTful-tjenester over DotNet-rammen. Og du behøver ikke udføre yderligere konfigurationsindstillinger for hver enhed separat. I disse dage foretrækker folk at bruge mere af mobilapps sammenlignet med desktopapplikationer, og det bliver derfor meget vigtigt at udvikle begge typer apps.
MVC giver på den anden side ren adskillelse af bekymringer, giver fuld kontrol over gengivet HTML, muliggør nem integration med Javascript-rammer og muliggør testdrevet udvikling.
Interessante artikler:
Hvorfor er Web API bedre end MVC
Korte point på MVC vs API
Billedkilde: Flickr.com/ Dennis / Yamashita
Forfatteren: Reema Oamkumar er engageret som en tankeleder på www.Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programmører til IT-virksomheder, agenturer og IT-afdelinger.