Lagdelt arkitektur

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 16. maj 2021; checks kræver 2 redigeringer .

I softwareudvikling er en  lagdelt arkitektur en klient-server-arkitektur , der adskiller funktionerne til præsentation, behandling og lagring af data. Den mest almindelige type lagdelt arkitektur er trelagsarkitektur .

N -tier applikationsarkitekturen giver en model, hvorved udviklere kan bygge fleksible og genbrugelige applikationer . Ved at opdele applikationen i lag af abstraktion får udviklere mulighed for at foretage ændringer i et specifikt lag i stedet for at omarbejde hele applikationen. En tre-lags arkitektur består normalt af et præsentationslag , et forretningslogiklag og et datalagringslag .

Selvom begreberne lag og niveau ofte bruges i flæng, er mange enige om, at der stadig er forskel på dem. Forskellen er, at et lag  er en mekanisme til logisk at strukturere de komponenter, der udgør en softwareløsning, mens et lag  er en mekanisme til fysisk at strukturere et systems infrastruktur. [1] [2] En tre-lags løsning kan nemt implementeres på et enkelt lag, såsom en personlig arbejdsstation . [en]

Lag

Det  arkitektoniske mønster "Layers" hjælper med at strukturere applikationer ved nedbrydning i grupper af delopgaver placeret på bestemte abstraktionsniveauer [3] .

Fælles lag

I logisk lagdelte informationssystemarkitekturer støder man oftest på følgende fire lag:

Bogen Domain-Oriented Design (DDD) beskriver nogle almindelige anvendelser for disse fire lag, selvom fokus flyttes mod domænelaget. [otte]

Nogle skelner også mellem forretningslogiklaget/-lagene og infrastrukturlaget/-lagene som et separat business-infrastructure-lag (BI). Dette lag omtales undertiden som "forretningslogiklaget på lavt niveau" eller "forretningsservicelaget". Dette lag er meget generelt og kan bruges i flere lag af en applikation (såsom valutaomregneren). [9]

Infrastrukturlaget kan opdeles i niveauer: tekniske tjenester på højt niveau og på lavt niveau. [9] Udviklere fokuserer ofte på dataadgangsmulighederne i infrastrukturlaget og refererer derfor kun til det i samtale som et dataadgangslag (i stedet for det mere generelle "infrastrukturlag" eller "tekniske servicelag"). Med andre ord tænkes andre former for tekniske tjenester ikke altid som en del af et bestemt lag.

Hvert lag afhænger kun af det underliggende lag og kan eksistere uden lagene ovenfor. Et andet almindeligt synspunkt er, at lag ikke altid er strengt afhængige af laget umiddelbart under dem. For eksempel i et afslappet lagdelt system kan et  lag afhænge af alle lagene under det. [3]

Se også

Kilder

  1. 1 2 Implementeringsmønstre (Microsoft Enterprise Architecture, Patterns and Practices) Arkiveret 4. november 2018 på Wayback Machine 
  2. Martin Fowler "The Architecture of Enterprise Software Applications" (2002). Addison Wesley. (Engelsk)
  3. 1 2 Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter; Stal, Michael (1996-08). Mønsterorienteret softwarearkitektur, bind 1, et system af mønstre. Wiley, august 1996. ISBN 978-0-471-95869-7 . Hentet fra http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html Arkiveret 29. november 2017 på Wayback Machine . (engelsk) . kapitel 2.
  4. Martin Fowlers Service Layer Arkiveret 18. november 2018 på Wayback Machine 
  5. Reference "Designmønstre" Serviceniveau . Hentet 1. oktober 2018. Arkiveret fra originalen 7. oktober 2018.
  6. Martin Fowler forklarer, at Service Layer er det samme lag som Application Layer Arkiveret 2. september 2018 på Wayback Machine 
  7. Sammenligning og diskussion af GRASP Controller og Application Layer / Service  Layer
  8. Domænedrevet design, bogen s. 68-74. Hentet fra http://dddcommunity.org/book/evans_2003/ . (eng.) Arkiveret 13. maj 2019 på Wayback Machine
  9. 1 2 Applying UML 2.0 and Design Patterns , 3. udgave, s . 203 Arkiveret 29. september 2018 på Wayback Machine ISBN 0-13-148906-2 

Links

Lagdelt arkitektur
Beskrevet i Design Patterns Ikke