Genom att använda Layered Architectures i ASP. NET-dummies

Ett sätt att utforma webbapplikationer är att fokusera på tydligt definierade lager av programmets arkitektur. Detta tillvägagångssätt liknar hur en arkitekt utformar en byggnad. Om du någonsin har sett detaljerade byggplaner för en skyskrapa, vet du att byggplanerna innehåller separata ritningar för byggnads-, ram-, tak-, VVS-, el- och andra golv i byggnaden.

Med en skiktad arkitektur kan specialister utforma och utveckla "golv" - kallade lager - oberoende, förutsatt att anslutningarna mellan lagren ( gränssnitten >) är noggrant tänkta. Skikten bör vara oberoende av varandra, så mycket som möjligt. Det betyder bland annat att man måste följa några måste-doser och shalt-nots:

Varje lager måste ha ett tydligt fokus.

• För att utforma lagren ordentligt måste du tydligt stava ut uppgifter och ansvar för varje lager.

Lager bör tänka på sin egen verksamhet.

• Om ett lager ansvarar för användarinteraktion får endast det lagret kommunicera med användaren. Andra lager som behöver få information från användaren måste göra det via användargränssnittet. Klart definierade protokoll måste ställas in för lagren att interagera med varandra.
• Samverkan mellan skikten sker endast genom dessa protokoll.

Observera att skikten inte är knutna direkt till någon speciell applikation. Till exempel kan en arkitektur fungera lika bra för ett online-beställningssystem och för ett onlineforum. Som ett resultat har skiktad arkitektur inget att göra med de ERD som definierar en databas eller dataflödesdiagrammen som definierar hur data strömmar i applikationen. Det är en separat struktur.

Hur många lager?

Det finns flera vanliga metoder för applikationsarkitektur som varierar beroende på hur många lager som används. Ett vanligt system är att bryta applikationen i två lager:

Application Layer:

• Utformningen av användargränssnittet och genomförandet av affärspolicy hanteras i detta lager. Detta lager kan också hantera transaktionslogik - koden som grupperar databasuppdateringar i transaktioner och säkerställer att alla uppdateringar inom en transaktion görs konsekvent. Dataåtkomstskikt:
• Den underliggande databasmotorn som stöder programmet. Detta skikt är ansvarigt för att upprätthålla databasens integritet. Några eller alla transaktionslogik kan implementeras i detta lager. I tvåskiktsmodellen är applikationslagret ASP. NET-webbsidor som definierar de sidor som presenteras för användaren samt kodens bakomliggande filer som implementerar programmets logik. Data Access Layer är databasservern som hanterar databasen, till exempel Microsoft SQL Server eller Oracle.

Observera att ASP. NET 2. 0 kräver inte att du placerar programmets logik kod i en separat kod bakom filen. I stället kan du interspiera logikkoden med presentationskoden i samma fil. Det är dock nästan alltid en bra idé att använda separata kod-bakomfiler för att skilja programmets logik från dess presentationsnummer. Alla program som presenteras i den här boken använder separata kod-bakom filer.

Uppdelningen mellan program- och dataåtkomstskikten är inte alltid så tydlig som den kan vara. Av prestationsskäl flyttas transaktionslogiken ofta till databasservern (i form av lagrade procedurer), och affärsregler implementeras ofta på databasservern med begränsningar och triggers. Sålunda hanterar databasservern ofta en del av applikationslogiken.

Om den här röra sig stör dig kan du använda en

arkitektur med tre lager , som lägger till ytterligare ett lager för att hantera företagsregler och policyer: Presentation Layer:

• Detta lager hanterar användaren gränssnitt. Regleringslag:
• Detta lager hanterar programmets affärsregler och policy. Till exempel, om en säljansökan ger rabatter till vissa användare, är rabattpolitiken implementerad i detta lager. Data Access Layer:
• Den underliggande databasmodellen som stöder programmet. Skapa ett separat lager för företagsregler gör att du kan skilja reglerna från databasdesignen och presentationslogiken. Affärsregler kan ändras. Genom att placera dem i ett separat lager har du en lättare uppgift att byta dem senare än om de är införlivade i användargränssnittet eller databasdesignen.

Model-View-Controller

En annan vanlig modell för utformning av webbapplikationer kallas

Model-View-Controller ( MVC ). I denna arkitektur är applikationen uppdelad i tre delar: Modell

• : modellen är i själva verket applikationsens affärsskikt. Det består vanligtvis av föremål som representerar de affärsenheter som utgör ansökan, till exempel kunder och produkter. Visa:
• Visa är applikationens användargränssnitt. I en webbapplikation består detta av en eller flera HTML-sidor som definierar programmets utseende och känsla. Controller:
• kontrollern hanterar händelser som behandlas av programmet. Händelserna genereras vanligtvis av användargränssnittsåtgärder, till exempel användaren klickar på en knapp eller väljer ett objekt från en rullgardinslista. I en typisk ASP. NET-applikation,. aspx-filen implementerar vyn Modul- och kontrollfunktionerna kombineras och hanteras av koden bakom filen. Således kan koden bakom filen betraktas som

modellstyrenheten . Du kan självklart skilja modell och kontrollfunktioner genom att skapa separata klasser för affärsenheterna. För enkelhetens skull behåller applikationerna i den här boken modell- och kontrollfunktionerna i koden bakom filen.