Hvad er MVC
I en tid, hvor webbrowseren i stigende omfang bliver anvendt som klient til enterprise-systemer, bliver teknikkerne fra de glade scripting-dage mere problematiske. Behovet for at anvende gængse programmeringsteknikker inden for webudvikling vokser. Model 2 er en måde at implementere design-mønsteret MVC i forbindelse med web-programmering. Det er mest udbredt i Java-verdenen, men kan også benyttes i forbindelse med ASP og PHP.
Hvad er MVC
Model-View-Controller paradigmet er en strategi for, hvorledes man separerer interaktionen mellem bruger og applikation i tre elementer. Et element bærer de data (Model), som skal kunne manipuleres af brugeren, fra selve brugerfladen (View), som er et andet element. Controlleren er det element, som styrer forbindelsen mellem View'et og modellen.
Oprindeligt blev MVC-paradigmet sat i verden i forbindelse med programmeringssproget Smalltalk, som var et af de første objektorienterede sprog. Siden da indgik MVC i de software-designmønstre (design patterns), som er mest kendt fra bogen Design Patterns (Gamma et al, 1995).
Design patterns, eller design-mønstre, er en måde at beskrive en række generiske, objektorienterede løsninger på ofte forekommende problemstillinger. Disse mønstre får stadig større betydning inden for mainstream-softwareudvikling. Eksempelvis er en lang række af Javas API'er baseret på disse mønstre.
MVC-mønstret består af tre hovedklasser: Model, View og Controller. Modellen repræsenterer data og den bagvedliggende applikation. View'et er fremvisningen af modellen (typisk den visuelle del af brugerfladen), og Controller-klassen håndterer interaktionen mellem brugeren og view'et.
Idéen med MVC-mønsteret er at skabe en løs kobling mellem de tre elementer for at gøre applikationerne mere fleksible og gøre det nemmere at genbruge og videreudvikle applikationerne.
MVC's model-begreb dækker over en klasse, som indkapsler applikationsobjektet, og modellen ved ikke hvorledes view'et er skruet sammen. View'et bygger derimod på modellen og er afhængig af den.
Hvis det lyder lidt luftigt, kan man tænke på et diagram i et regneark. En række data, celler, i regnearket er modellen. Modellen kan anskueliggøres på flere måder som for eksempel et lagkagediagram, et søjlediagram og så videre, alt afhængig af brugerens interaktion med Controlleren.
MVC og webapplikationer
MVC og webapplikationer
Behovet for MVC i forbindelse med webapplikationer er opstået gradvis i forbindelse med den generelle udvikling på webområdet. De første typer af webapplikationer var ofte baseret på CGI-scriptingsprog som Perl, hvor HTML-koden skrives linie for linie til browseren. Problemet med denne måde er en lav grad af fleksibilitet i forbindelse med udformning og de data, som skal returneres til klienten.
Teknikker som PHP, ASP og JSP løser en del af problemet ved at give mulighed for at indlejre logikken mellem HTML-koderne, hvilket er en nemmere og mere fleksibel måde at håndtere problemet på.
Det grundlæggende problem, at data og præsentation blandes, bliver dog ikke løst, og det er stadig svært at separere udviklernes roller. Denne metode kræver stadig et snævert samarbejde mellem programmør og webdesigner.
Ved at benytte JavaBeans og Tag-biblioteker opnås en større grad af separation, og med Model 2-arkitekturen øges denne separation endnu en tand.
Lad os se på en konkret sammenligning mellem den måde, som JSP benyttes som beskrevet i forrige artikel, hvilket betegnes som Model 1, og MVC-arkitekturen i Model 2.
I Model 1-arkitekturen sender browseren en forespørgsel til serveren (1), som internt behandler forespørgslen i en JSP-fil. Som vi gennemgik i forrige artikel kan forretningslogikken være indkapslet i en eller flere JavaBeans, som JSP-siden instantierer (2). Typisk vil disse JavaBeans tilgå et backend-datalager eller enterprise-servere, som eksempelvis ordrestyrings-systemer med videre (3). Når bønnerne har udført deres arbejde, kan resultatet indlejres i JSP-siden (2) på en måde, så det giver mening for brugeren. Derefter returnerer JSP-filen det genererede svar til browseren (4).
I Model 2-arkitekturen er de opgaver, som JSP-filen i forrige diagram varetager, nu opdelt i en servlet, som har controller-rollen i MVC-paradigmet, og en eller flere JSP-sider, som konstruerer de views, som forespørgslen kan resultere i.
Servletten modtager forespørgslen (1), og på baggrund af forespørgslens art instantieres de relevante JavaBeans (2), som repræsenterer model-rollen i MVC-arkitekturen.
Controller-servletten videresender forespørgslen til den bestemte JSP-fil, som håndterer det relevante view. Denne JSP-side henter så de data, som den skal benytte for at generere sit view, fra de bønner, som servlet-controlleren har instantieret (4). Og så kan JSP-siden returnere det genererede view til browseren (5).
Det skal nævnes, at Model 1-arkitekturen ofte vil bestå af en række JSP-sider, som hver for sig håndterer én bestemt type forespørgsel, hvor ideen i Model 2 er, at servletten skal håndtere alle de forespørgsler som applikationen håndterer. På denne måde håndterer controller-servletten al interaktion mellem bruger og applikation i stedet for at sprede denne logik over en række JSP-sider.
De forskellige views er derimod ofte lagt ud i forskellige JSP-filer. Man kan tænke på disse views som en række skabeloner, som forsynes med de relevante datasæt.
Derudover behøver controller-servletten ikke nødvendigvis at instantiere de berørte JavaBeans. Instantieringen kan også foregå i de JSP-sider, som håndterer view'et, på samme måde som i Model 1.
Videre end Model 2
Videre end Model 2
En udmærket artikel i vor amerikanske søsterpublikation JavaWorld gennemgår et simpelt kode-eksempel på anvendelse af model 2.
Jakarta, som er Apache-gruppens Java-fraktion, har udviklet et framework, Struts, som bygger på Model 2, og som kan lette udviklingen af Model 2-baserede applikationer.
Endnu videre end Model 2 går projekter som Cocoon, der abstraherer genereringen af præsentationslaget. Cocoon er udviklet i Java og bygger på XML-definitionsfiler i stedet for rå kode, hvilket i princippet kan nedsætte behovet for udvikling af webapplikationer væsentligt.
Specielt Cocoons radikale fleksibilitet i forbindelse med uddata gør projektet interessant, da der i fremtiden givetvis vil være et stigende krav om at kunne udvikle til et bredere spektrum af slutmedier end blot desktop-browsere. Og det problem kan Model 2 ikke løse uden videre.
