Af Michell Cronberg, Alt om Data
Denne artikel er oprindeligt bragt på Alt om Data. Computerworld overtog i november 2022 Alt om Data. Du kan læse mere om overtagelsen her.
Det er ikke nemt at være Microsoft ASP.NET-udvikler i dag. Ikke fordi de forskellige programmeringsmodeller er svære at bruge, men fordi det efterhånden kan være svært at gennemskue junglen af forskellige teknologier, som alle i en eller anden form er bundet til Microsofts ASP.NET-platform. Jeg nævner i flæng – ASP.NET Web Forms, ASP.NET MVC, ASP.NET Web Pages, ASP.NET Web API og ASP.NET SPA.
Herudover har Microsoft, om ikke bundet sig, så i hvert fald kraftigt anbefalet en del forskellige eksterne JavaScript-biblioteker som jQuery, Modernizr, Knockout og SignalR. Alle gode tilføjelser til en webapplikation, men det gør absolut ikke overskueligheden større.
Det må være tid til at stoppe op og få et overblik – her er min guide til ASP.NET anno 2012.
Klassisk ASP
I 1996 frigav Microsoft sin første version af Active Server Pages – forkortet ASP. Den blev hurtigt meget populær, fordi den ved hjælp af et simpelt scriptsprog (primært VBScript) gjorde det nemt at skabe dynamiske websider. Den senest frigivne version af teknologien er 3.0 fra 2000, og den er ikke blevet opdateret siden.
Selvom ASP (tit omtalt klassisk ASP eller ASP3) fortsat er supporteret af Microsoft, er der næppe nogen, der bruger den til at udvikle nye webapplikationer med. Hertil er den alt for langsom, scriptsproget er for begrænset, og der findes ingen ordentlige udviklingsmiljøer. Der lever dog fortsat tusinder af klassiske ASP-applikationer på nettet, og mange af dem vil sikkert eksistere, indtil Microsoft endeligt lukker for supporten om nogle år.
ASP.NET Web Forms
Web Forms er den gode gamle, og meget populære, måde at skabe webapplikationer på. Programmeringsmodellen er over 10 år gammel og er i skrivende stund i version 4.5 frigivet sammen med Visual Studio 2012.
Web Forms benytter et framework bestående af kontroller, som er intelligente nok til at skabe html, der passer til den browser, der efterspørger siden. Det gør det muligt at skabe sider meget hurtigt uden nødvendigvis at have særlig meget forstand på hverken html, JavaScript eller css.
Sammen med features som eksempelvis master-pages til at styre design, temaer til at styre udseende og effektiv brug af ressourcefiler til globalisering kan man nemt og hurtigt binde sider sammen til et site. Yderligere er supporten for AJAX-udvikling vanvittig snedigt implementeret med kontroller, der betyder, at selv en novice kan udvikle AJAX-funktionalitet.
Udvikling med Web Forms er hændelsesorienteret og i den grad RAD (rapid application development), og den minder meget om udvikling af Windows-applikationer – bortset fra at brugerfladen ender i html naturligvis.
ASP.NET MVC
I 2009 frigav Microsoft den første version af sit på det tidspunkt eneste alternativ til Web Forms kaldet ASP.NET MVC, og den er efterfølgende opdateret til version 4.0 frigivet i 2012. Den er altså et framework, som Microsoft har stor opmærksomhed på med en ny version hvert år.
Teknologien benytter et Model-View-Controller-design (heraf navnet MVC) til at adskille web-applikationen i forskellige lag. I modellaget vil der typisk være dataadgang og forretningslogik. I det mellemste controller-lag kobles http-forespørgsler sammen med kode, som kommunikerer med henholdsvis model-laget og view-laget, og i view-laget skabes den html, som controller-laget så kan sende retur til browseren.
MVC indeholder en masse indbyggede features relateret til brug af arkitekturen på nettet – herunder sammenkobling af http-kald til metodekald, objekt-mapping, forskellige måder at skabe html på, validering, test og meget mere.
ASP.NET Web Pages
I starten af 2011 frigav Microsoft sin tredje teknologi til udvikling af webapplikationer kaldet ASP.NET Web Pages, og det skete i forbindelse med et nyt gratis udviklingsmiljø kaldet WebMatrix (Visual Studio kan dog også benyttes). Programmeringsmodellen giver mulighed for at skabe sider, hvor html, serversidekode og klientsidekode (JavaScript) typisk er kombineret – på samme måde, som den klassiske ASP, PHP eller andre lignende teknologier fungerer. Der er ingen direkte adskillelse mellem serverlogik og klientkode, som eksempelvis Web Forms skaber ved at placere serversidekode i separate filer, eller som MVC gør ved at arbejde i separate lag.
Web Pages er som skabt til undervisning, og jeg bruger det eksempelvis en del som instruktør til at lære studerende grundlæggende webudvikling – for så efterfølgende at flytte fokus til MVC. Mange benytter også Web Pages til at prototype en webside eller en konkret funktionalitet, og udviklere, som kommer fra klassisk ASP eller PHP, vil omgående ”føle sig hjemme”. Det er uden tvivl også en af årsagerne til, at Web Pages overhovedet eksisterer – hvis en udvikler først lærer at bruge .NET, C#/VB.NET og Web Pages, er der ikke langt til Web Forms eller MVC.
ASP.NET Web API
Sidste skud på stammen er ASP.NET Web API, som er endelig frigivet sammen med ASP.NET MVC 4.0 i år. Den kan bruges til at skabe et ”ægte” http-baseret servicelag, som eksempelvis kan tilgås fra en browser via JavaScript eller fra en (platformsuafhængig) klientapplikation og er et alternativ til WCF-services (Windows Communication Foundation).
Programmeringsmodellen indeholder en del features, som letter udviklingen af et servicelag, herunder at lade klient og server selv finde ud af, hvilken protokol der skal benyttes (eksempelvis JSON eller XML), objekt-mapping, validering, support for et REST-baseret interface samt muligheden for at bruge Web API uden IIS (webserver).
Selvom Web API blev frigivet med MVC, kan det også benyttes sammen med Web Forms.
ASP.NET Single Page Application
Slutteligt lurer SPA i kulissen og forventes frigivet endeligt i 2012. SPA er en forkortelse for Single Page Application og består af server- og klientelementer, som hjælper med til at skabe moderne webapplikationer, hvor fokus især er lagt på interaktion med brugeren direkte i browseren. Serverside består typisk kun af et servicelag (Web API) samt metoder til at skabe en overordnet html-side, mens den resterende funktionalitet håndteres af JavaScript. Microsoft benytter her, ud over egne scripts, et væld af forskellige kendte JavaScript-bib- lioteker som eksempelvis jQuery (DOM- og AJAX-funktionalitet), Upshort.js (data-lag), Knoutout (databinding), Modernizr (html 5-kontrol) samt en del andre.
Selvom de andre programmeringsmodeller også bruger en masse JavaScript, er SPA meget anderledes fra både Web Forms, MVC og Web Pages. Meningen er at skabe applikationer (typisk baseret på html 5), som opfattes af brugeren som en ”rigtig” applikation med en effektiv brugerflade, selvom den afvikles i en browser. Eksempler på eksisterende SPA-applikationer er eksempelvis GMail, Trello og Facebook.
Hvad skal jeg vælge?
Der er ikke noget at sige til at udviklere kan miste overblikket med alle de programmeringsmodeller, men to typer af applikationer giver dog sig selv. Hvis du skal udvikle et http-servicelag, bør ASP.NET Web API være et oplagt valg, og ASP.NET Web Pages er ikke skabt til at håndtere større websites, men er til gengæld meget effektivt til prototyper, enkelte sider samt til brug ved undervisning.
SPA-applikationerne har måske en stor fremtid – der dukker flere og flere op af slagsen. Denne type af applikation er dog ikke decideret bundet til en serverteknologi, men arbejder i stedet med et servicelag og en masse JavaScript-biblioteker. Om Microsofts SPA-skabeloner slår an, når de frigives, er meget svært at spå om, men det er nok helt rigtigt set af Microsoft at spille med på den hest også. Hvis SPA-toget kører, så kører det nu, og det bliver meget spændende at følge med i, om SPA bider sig fast de næste par år.
Men det reelle valg til en større traditionel serverbaseret web-applikation står mellem den gamle Web Forms-model og den nyere MVC-model, og her er forskellene ret tydelige, som det fremgår af den separate boks. Men det er svært at vælge. Mange vælger MVC i øjeblikket, fordi det tvinger udviklerne til at skabe en lagopdelt applikation, som er nem at teste, og som er mere fremtidssikret end Web Forms. Andre er faldet for Microsofts prioritering af MVC frem for Web Forms, og nogen vælger blot MVC, fordi det er det nye. Der er også mange, som holder sig til Web Forms, fordi det er en gennemtestet og meget effektiv programmeringsmodel.
Jeg tror ikke, der er nogen tvivl om, at Microsoft holder fast i begge teknologier – også på længere sigt. Måske vil vi endda se en eller anden form for sammensmeltning af alle webteknologierne i en hybridlignende applikation. Flere i Microsoft taler åbent om, at fremtiden er et samlet ASP.NET, og der er sågar i nyere præsentationer set glimt af Visual Studio-udvidelser, som understøtter dette.
Om der skal vælges Web Forms, MVC eller måske SPA, hvis applikationen egner sig til dette, må bero på en gennemgang af en kravspecifikation og så et stort whiteboard med en masse plusser og minusser. n
Web Forms er i den grad RAD (Rapid Application Development). Det går lynende hurtigt at udvikle selv et stort site. Yderligere behøver man ikke vide særlig meget om html og JavaScript for at arbejde med Web Forms.
I MVC kan du i langt højere grad styre, hvilken html der genereres, hvilket betyder, at du med MVC nemmere kan tilpasse et site til nye standarder.
MVC er skabt med ”korrekt” applikationsdesign for øje. Det er nemt at skabe en applikation i MVC, som overholder et gennemtestet design-pattern med separate lag, som er nemme at teste individuelt. Du kan godt udvikle arkitektonisk rigtige Web Forms-applikationer, men det kan også meget hurtigt blive til spaghettikode, hvis du ikke er opmærksom.
MVC er langt tættere på http-protokollen end Web Forms. MVC bør med sin lagopdelte arkitektur være nemmere at vedligeholde i fremtiden. At kunne skifte hele brugerfladen uden at røre ved data-, forretnings- og http-lag kan vise sig at være guld værd på et tidspunkt.
Web Forms-kontrolbaserede AJAX-support er baseret på Microsofts egne AJAX-biblioteker, og Microsoft udtaler selv, at man fremover vil satse på jQuery AJAX. MVC kan nemt skabe forskellig html til en traditionel browser og en mobil browser.
Der er, så vidt jeg ved, ikke en større undersøgelse, som viser den reelle forskel i performance mellem Web Forms og MVC, men de færre abstraktionslag i MVC bør være en fordel.
Der er langt flere Web Forms-udviklere, end der er MVC-udviklere, men MVC er tydeligvis en teknologi på vej frem.
MVC opdateres med langt højere frekvens end Web Forms. Det behøver dog ikke være en ulempe for Web Forms (måske er Web Forms bare så gennemarbejdet, så der ikke er meget mere at udvide med), men det viser måske lidt om Microsofts interne prioritering. MVC (og Web Pages samt API) er open source i modsætning til Web Forms.