Innholdsfortegnelse:
- Det finnes flere vanlige tilnærminger til applikasjonsarkitektur som varierer avhengig av antall lag som brukes. Én vanlig ordning er å bryte applikasjonen i to lag:
- En annen vanlig modell for utforming av webapplikasjoner kalles
Video: Arbeidsmiljø i Norsborgsdepån 2024
En tilnærming til å designe webapplikasjoner er å fokusere på klart definerte lag av programmets arkitektur. Denne tilnærmingen ligner på hvordan en arkitekt designer en bygning. Hvis du noen gang har sett detaljerte byggeplaner for en skyskraper, vet du at konstruksjonsplanene inkluderer separate tegninger for fundamentet, rammen, taket, rørleggerarbeidet, elektriske og andre gulv i bygningen.
Med en lagdelt arkitektur kan spesialister utforme og utvikle "gulvene" - kalt lag - uavhengig, forutsatt at forbindelsene mellom lagene ( grensesnittene >) er nøye gjennomtenkt. Lagene skal være uavhengige av hverandre, så mye som mulig. Blant annet betyr det at du må ha noen må-doser og ikke-å-være:
Hvert lag må ha et klart definert fokus.
- For å designe lagene riktig må du tydelig stave opp oppgavene og ansvarene til hvert lag.
- Hvis ett lag er ansvarlig for brukerinteraksjon, har bare det laget lov til å kommunisere med brukeren. Andre lag som trenger å få informasjon fra brukeren, må gjøre det gjennom brukergrensesnittlag. Klart definerte protokoller må konfigureres for lagene å samhandle med hverandre.
- Samspill mellom lagene skjer bare gjennom disse protokollene.
Hvor mange lag?
Det finnes flere vanlige tilnærminger til applikasjonsarkitektur som varierer avhengig av antall lag som brukes. Én vanlig ordning er å bryte applikasjonen i to lag:
Application Layer:
- Utformingen av brukergrensesnittet og implementeringen av forretningspolitikker håndteres i dette laget. Dette laget kan også håndtere transaksjonslogikk - koden som grupperer databaseoppdateringer i transaksjoner og sikrer at alle oppdateringer i en transaksjon blir gjort konsekvent. Data Access Layer:
- Den underliggende databasemotoren som støtter programmet. Dette laget er ansvarlig for å opprettholde databasenes integritet. Noen eller alle transaksjonslogikken kan implementeres i dette laget. I tolagsmodellen er Application Layer ASP. NET-websider som definerer sidene som presenteres for brukeren, samt kodene bak filene som implementerer programmets logikk. Data Access Layer er databaseserveren som administrerer databasen, for eksempel Microsoft SQL Server eller Oracle.
Merk at ASP. NET 2. 0 krever ikke at du plasserer programmets logikkode i en separat kode bak fil. I stedet kan du kryptere logikkoden med presentasjonskoden i samme fil. Det er imidlertid nesten alltid en god idé å bruke separate kode-bak-filer for å skille programmets logikk fra presentasjonskoden. Alle programmene som presenteres i denne boken, bruker separate kode-bak-filer.
Deling mellom applikasjons- og datatilgang lagene er ikke alltid så klar som mulig. Av ytelsesmessige årsaker blir transaksjonslogikken ofte skiftet til databaseserveren (i form av lagrede prosedyrer), og forretningsregler blir ofte implementert på databaseserveren med begrensninger og utløsere. Dermed håndterer databaseserveren ofte noen av programlogikken.
Hvis dette rotet plager deg, kan du bruke en
trelagsarkitektur , som legger til et ekstra lag for å håndtere forretningsregler og retningslinjer: Presentasjonslag:
- Dette laget håndterer brukeren grensesnitt. Forretningsreglerlag:
- Dette laget håndterer programmets forretningsregler og retningslinjer. For eksempel, hvis en salgsapplikasjon gir rabatter til bestemte brukere, er rabattpolitikken implementert i dette laget. Data Access Layer:
- Den underliggende databasemodellen som støtter programmet. Opprette et eget lag for forretningsregler gjør det mulig å skille mellom reglene fra databasedesign og presentasjonslogikk. Forretningsregler kan endres. Ved å plassere dem i et eget lag, har du en lettere oppgave å endre dem senere enn om de er innlemmet i brukergrensesnittet eller databasedesignet.
Modell-View-Controller
En annen vanlig modell for utforming av webapplikasjoner kalles
Model-View-Controller ( MVC ). I denne arkitekturen er applikasjonen delt inn i tre deler: Modell
- : modellen er i virkeligheten applikasjonsvirksomhetslaget. Det består vanligvis av gjenstander som representerer forretningsenheter som utgjør søknaden, for eksempel kunder og produkter. Vis:
- visningen er applikasjonens brukergrensesnitt. I en webapplikasjon består dette av en eller flere HTML-sider som definerer utseendet på applikasjonen. Controller:
- kontrolleren styrer hendelsene som behandles av programmet. Hendelsene genereres vanligvis av brukergrensesnitthandlinger, for eksempel brukeren klikker på en knapp eller velger et element fra en rullegardinliste. I en typisk ASP. NET applikasjon,. aspx-filen implementerer visningen; Modell- og kontrollfunksjonene blir kombinert og håndtert av kode-bak-filen. Dermed kan kode-bak-filen betraktes som
modellkontrolleren . Du kan selvsagt skille modell- og kontrollfunksjonene ved å opprette separate klasser for forretningsenhetene. For enkelhets skyld beholder programmene i denne boken modellen og kontrollfunksjonene kombinert i kode-bak-filen.
