For lenge siden, før webapplikasjoner, oppsto idéen om 3-lags applikasjoner. Idéen var ganske enkel og innevarslet et paradigmeskifte for applikasjonsstruktur. Dette var i Client/Server - æraen, husk det, systemer typisk bygget som Windows applikasjoner som snakket med en databaseserver.
3-lagsmodellen:
Hovedårsaken til at dette ble spådd til å representere fremtidens applikasjonsstruktur var:
- man trenger bare billige tynnklient-maskiner
- All applikasjonslogikk legges i et separat lag i stedet for å spres rundt omkring i den fete klienten
- Det ville muliggjøre multi-plattform klienter å koble seg mot en og samme server
Web var på full vei inn, og 3-lags modellen passet perfekt inn i dette bildet. Snart ville store, prosessorintensive, minneintensive, dyre kontor-PCer være historie. Fremtiden var ideell for billige tynn-klient maskiner.
Så - hva er problemet med denne modellen ?
Vi starter med hva som er den gode idéen med denne modellen - å holde kjernefunksjonalitet ute av klientapplikasjonene. De gamle C/S-applikasjonene var fullpakket med slik funksjonalitet, siden den kun snakket med databasen. Det ble gjort forsøk på å avhjelpe dette problemet, som å utvikle server-side prosedyrer for basisfunksjonalitet. Dette etterliknet det å ha et midtre applikasjonslag og utgjorde en "pseudo-3-lags struktur". Det bør vel også nevnes når man snakker om webapplikasjoner, at det er ingen måte å unngå å ha en applikasjonsserver.
Idéen var å holde forretningslogikken ute av klientapplikasjonen. Klienten ville utgjøre et passiv brukergrensesnitt og ikke holde noen informasjon om hvorvidt en ordre kunne effektueres (om flere data trengtes eller kunden er svartelistet, f.eks.). Mye enklere, men hva med brukeropplevelsen ? Ville ikke dette lett ende opp som en primitiv webapplikasjon - send inn og få tilbake røde feilmerker i retur, send inn igjen og håpe de går bort ?
Hvordan fyller du inn data i en nedtrekksliste basert på tidligere valg i en radiogruppe ? jeg tror du vet svaret nå - du kan ikke. Klientapplikasjonen trenger å speile forretningsmodellen for å gi et rikt brukergrensesnitt og en -opplevelse som man normalt ville forvente fra de gamle C/S-applikasjonene.
Jeg tviler på idéen om å holde forretningslogikken unna klienten, på grunn av svaret på dette spørsmålet: - Hvilke forretningsregler trenger ikke å manifesteres i brukergrensesnittet ? Er det ikke slik at et godt, responsivt UI forsyner brukeren med all nødvendig hjelp og informasjon for å gjøre ting rett og effektivt ?
Hvordan komme rundt begrensningene ?
Det er ganske enkelt, og alle webprogrammerere av i dag ved dette; klienten trenger å hente (meta)data fra forretningslogikklaget for å kunne reflektere forretningsmodellen i UI. Det er ikke helt trivielt, og hvis det gjøres via bibliotek og komponenter finner man seg lett i den samme situasjonen som man var med RAD-alderens (VB, Delphi) databundne komponenter. Som jeg ville presentere meg sent på 90-tallet: "Workarounds er mellomnavnet mitt".
Vel, konseptet tynnklient døde. Av en grunn.