Pri načrtovanju nivoja storitve v vaših aplikacijah je izbira tehnologije, ki se bo uporabljala v ravni storitve, odvisna od številnih dejavnikov. V tem članku bom predstavil razpravo o tem, kdaj in kako se lahko odločite za izbiro prave tehnologije za izvajanje storitvene plasti pri načrtovanju aplikacij v .Net.
Dva pomembna kandidata, ki ju imate pri oblikovanju storitvene plasti v .Net, sta WCF in spletni API. WCF je razvojna platforma za SOA - ponuja številne funkcije in podpira številne različne transportne protokole. Medtem ko je WCF enoten okvir za gradnjo storitveno usmerjenih aplikacij, je spletni API lahka alternativa za gradnjo RESTful storitev, ki jih lahko porabi veliko različnih odjemalcev. Storitve RESTful uporabljajo osnovni HTTP in so preproste z veliko manj koristnega tovora v primerjavi s storitvami SOAP. WebHttpBinding v WCF lahko uporabite za izdelavo storitev, ki niso SOAP RESTful, prek HTTP. WCF je veliko bolj vsestranski v smislu, da lahko podpira številne transportne protokole - HTTP, TCP itd. WCF lahko izkoristite za izgradnjo varnih, zanesljivih in transakcijskih storitev, ki lahko podpirajo sporočanje, dupleksno komunikacijo in hitre transportne kanale, kot je TCP , Poimenovane cevi ali UDP.
Če morate prek HTTP zgraditi lahke storitve, usmerjene k virom, ki lahko izkoristijo vse funkcije protokola HTTP, uporabljajo različice, nadzor predpomnilnika za brskalnike in sočasnost z uporabo oznak Etags, je spletni API dobra izbira. Izberite spletni API pred WCF v storitveni plasti, če želite svoje storitve izpostaviti širokemu krogu strank, tj. Spletnim brskalnikom, mobilnim telefonom, tabličnim računalnikom itd. Spletni API je majhen in primeren za naprave, ki imajo omejeno pasovne širine kot pametni telefoni. Ena glavnih omejitev, s katero sem se soočil med uporabo WCF, je obsežna konfiguracija - spletni API je veliko preprostejši in enostavnejši za uporabo. Priznam, da je WCF veliko bolj vsestranski v primerjavi s spletnim API-jem, vendar, če ne potrebujete funkcij, ki jih ponuja WCF in potrebujete le RESTful storitve prek HTTP-ja, bi vedno raje imel spletni API, saj je lahek in enostaven za uporabo .
Prav tako bi rad predstavil razpravo o razlikah med spletnim API-jem in ASP.Net MVC, saj obstajajo določene napačne predstave o tem, kdaj izbrati enega pred drugim. Izbira med ASP.Net MVC in Web API je odvisna od številnih dejavnikov. Preden se odločite za uporabo katerega koli od njih, morate vedeti nekaj premislekov.
Upoštevajte, da spletni API za preslikavo na ustrezne poti uporablja glagole HTTP in s tem preslikavo, ki temelji na glagolih HTTP. Ne morete imeti preobremenjenih metod za isti glagol HTTP za določeno pot. Pri izbiri med ASP.Net MVC in spletnim API-jem se morate zavedati te omejitve načrtovanja (čeprav so na voljo rešitve). Za razliko od ASP.Net MVC, spletni API uporablja usmerjanje na podlagi glagolov HTTP in ne URI-jev, ki vsebujejo dejanja. Tako lahko s pomočjo spletnega API-ja napišete storitve RESTful, ki lahko izkoristijo protokol HTTP - lahko oblikujete storitve, ki jih je lažje preizkusiti in vzdrževati. Usmerjanje v spletnem API-ju je veliko preprostejše in lahko brez težav izkoristite pogajanja o vsebini. Model usmerjanja v ASP.Net MVC vključuje dejanja v URI-jih.
Druga stvar, ki bi jo želeli razmisliti, je, ali želite, da je vaša funkcionalnost izpostavljena določeni aplikaciji, ali pa bi morala biti splošna. Če želite svoje storitve izpostaviti samo eni aplikaciji, uporabite ASP.Net MVC - krmilnik v aplikaciji ASP.Net MVC je specifičen za aplikacijo. Nasprotno, želeli bi pristop spletnega API-ja, če vaše poslovne potrebe zahtevajo splošno izpostavljenost funkcionalnosti. Raje bi uporabil pristop spletnega API-ja, če je funkcionalnost bolj osredotočena na podatke, in pristop ASP.Net MVC, če je funkcionalnost bolj osredotočena na uporabniški vmesnik.
Če želite, da krmilnik vrne podatke v več oblikah, kot so JSON, XML itd., Morate uporabiti spletni API prek ASP.Net MVC. Prav tako je določanje oblike podatkov v spletnem API-ju enostavno in enostavno konfigurirati. Spletni API dosega tudi ASP.Net MVC v svoji zmožnosti samostojnega gostovanja (podobno kot WCF). Potrebovali bi krmilnike ASP.Net MVC, ki bi gostovali na istem spletnem strežniku, kjer je gostovala aplikacija, ker so krmilniki ASP.Net MVC del iste aplikacije. Nasprotno, krmilnike spletnega API-ja lahko gostite tudi zunaj IIS-ja - lahko ga gostite v lahkem po meri gostitelju in dovolite, da storitev porabi veliko različnih odjemalcev.
