mboost-dp1
2-tier eller 3-tier arkitektur?
Jeg sidder her som kæmpe newb og kan ikke rigtig finde ud af om min hjemme side er 2-tier, eller 3-tier..
Ja, det er næsten utroligt!?
Min situation er som følger.
Min hjemmeside ligger på en server, der indeholder præsentations lag, forretnings logik, samt kaldene til mine database.
Jeg tænker så at det er en 2-tier klient-server arkitektur. Hvor brugerens browser er klienten og min server, ja, er serveren.
Hmm.. Jamen hvad så med databasen? er den ikke også et lag?
Klient -> server -> database? altså 3 tier arkitektur?
Eller skal der en opdeling af præsentation og forretnings lag på seperate servere, før det går hen og bliver en 3-tier arkitektur?
Ja, det er næsten utroligt!?
Min situation er som følger.
Min hjemmeside ligger på en server, der indeholder præsentations lag, forretnings logik, samt kaldene til mine database.
Jeg tænker så at det er en 2-tier klient-server arkitektur. Hvor brugerens browser er klienten og min server, ja, er serveren.
Hmm.. Jamen hvad så med databasen? er den ikke også et lag?
Klient -> server -> database? altså 3 tier arkitektur?
Eller skal der en opdeling af præsentation og forretnings lag på seperate servere, før det går hen og bliver en 3-tier arkitektur?
Pjust (1) skrev:
Eller skal der en opdeling af præsentation og forretnings lag på seperate servere, før det går hen og bliver en 3-tier arkitektur?
Ja. F.eks. kan dit præsentationslag snakke med forretningslaget over en webservice eller ligende. Derefter snakker dit forretningslag med databasen.
Om det behøver at være på forskellige servere (fysiske) det er noget andet. Hele lortet kan godt ligge på en, men så går ideen nok lidt af arkitekturen.
#3
Så vidt jeg forstår på dig, så kører dit logik og præsentation i samme kildekode, ikke sandt? Eller har du et sted hvor logik og præsentation er sepereret? (webservice eller ligende imellem logik og præsentation) Hvis ikke, så er det vel kun 2 tier. Hvis det er 3 tier, så skal det være muligt at ligge logik på en seperat server fra præsentation, det behøves ikke at ligge på forskellige servere, men det skal være muligt.
Så vidt jeg forstår på dig, så kører dit logik og præsentation i samme kildekode, ikke sandt? Eller har du et sted hvor logik og præsentation er sepereret? (webservice eller ligende imellem logik og præsentation) Hvis ikke, så er det vel kun 2 tier. Hvis det er 3 tier, så skal det være muligt at ligge logik på en seperat server fra præsentation, det behøves ikke at ligge på forskellige servere, men det skal være muligt.
#4 Min præsentation er adskilt fra logik på den måde at det ligger i forskellige filer. Jeg har en mappe med templates (præsentation) og en mappe med logik ( funktionalitet )
her kan du se opdelingen af systemet:
http://billedeupload.dk/?v=w5gHE.png
Template filer kalder funktioner i logik klasserne, ved f.eks. tryk på en "submit" knap. Er det så adskilt ? Det ligger på samme server, men er ikke blandet. .
her kan du se opdelingen af systemet:
http://billedeupload.dk/?v=w5gHE.png
Template filer kalder funktioner i logik klasserne, ved f.eks. tryk på en "submit" knap. Er det så adskilt ? Det ligger på samme server, men er ikke blandet. .
#1
Det er jo et spørgsmål om terminologi.
Men her er som jeg anbefaler at bruge termerne.
Du har allerede 3 tiers:
* client tier (browser)
* application tier (PHP)
* database tier
Udfra din tekst så er dit application tier opdelt i 3 layers:
* presentation layer
* business logic layer
* data access layer
Udfra dit billede så er dit application tier opdelt i 2 layers:
* presentation layer
* business logic layer
Hvis du splittede op således at din presentation PHP kode og din logic PHP kode kunne køre på forskellige servere så ville du have 4 tiers:
* client tier (browser)
* frontend application tier (PHP)
* backend applicatuion tier (PHP)
* database tier
hvor frontend application tier vil have 2 layers:
* presentation layer
* proxy layer
og backend application tier vil have 3 layers:
* service layer
* business logic layer
* data access layer
Forvirringen kommer fordi mange også kalder layers for tiers.
Og med to forskellige betydninger af ordet tier, så er det meget svært at bruge ordet til at forklare noget.
Derfor anbefaler jeg at bruger tier og layer.
Det er jo et spørgsmål om terminologi.
Men her er som jeg anbefaler at bruge termerne.
Du har allerede 3 tiers:
* client tier (browser)
* application tier (PHP)
* database tier
Udfra din tekst så er dit application tier opdelt i 3 layers:
* presentation layer
* business logic layer
* data access layer
Udfra dit billede så er dit application tier opdelt i 2 layers:
* presentation layer
* business logic layer
Hvis du splittede op således at din presentation PHP kode og din logic PHP kode kunne køre på forskellige servere så ville du have 4 tiers:
* client tier (browser)
* frontend application tier (PHP)
* backend applicatuion tier (PHP)
* database tier
hvor frontend application tier vil have 2 layers:
* presentation layer
* proxy layer
og backend application tier vil have 3 layers:
* service layer
* business logic layer
* data access layer
Forvirringen kommer fordi mange også kalder layers for tiers.
Og med to forskellige betydninger af ordet tier, så er det meget svært at bruge ordet til at forklare noget.
Derfor anbefaler jeg at bruger tier og layer.
#8
Hej arne.
Tak for den meget fine forklaring.
Kan du nævne fordelene ved at lave det 4-tier istedet for 3-tier? Jeg tænker f.eks. at det vil gøre det muligt at tilføje sepearte præsentation-tiers til både mobiler og tablets og stadig bruge den samme funktionalitet?
Eller vil det bare gøre applikationen hurtigere?
Hej arne.
Tak for den meget fine forklaring.
Kan du nævne fordelene ved at lave det 4-tier istedet for 3-tier? Jeg tænker f.eks. at det vil gøre det muligt at tilføje sepearte præsentation-tiers til både mobiler og tablets og stadig bruge den samme funktionalitet?
Eller vil det bare gøre applikationen hurtigere?
#9
Den hyppigste grund til at lave et split af application tier er fordi man vil have frontend og backend i forskellige teknologier. Hvis begge er PHP, så er det ikke tilfældet.
Andre mulige årsager er:
* sikkerhed
* skalering
* mulighed for forskellige frontends [som du selv nævner]
Den hyppigste grund til at lave et split af application tier er fordi man vil have frontend og backend i forskellige teknologier. Hvis begge er PHP, så er det ikke tilfældet.
Andre mulige årsager er:
* sikkerhed
* skalering
* mulighed for forskellige frontends [som du selv nævner]
#9 Som arkitekturen er nu, er det så ikke muligt at lave:
forskellige frontends?
skalering?
Man kan vel godt tilføje flere db-servere og flere app-servere? da det er 3-tier. .
og vel også forskelligt udseende, ved at kontrollere hvilken hardware (mobil, tablet, pc) der tilgåes fra?
//undskyld hvis jeg spørger for meget, jeg fornemmer bare at du har styr på lortet, så vil suge alt det jeg kan! :)
forskellige frontends?
skalering?
Man kan vel godt tilføje flere db-servere og flere app-servere? da det er 3-tier. .
og vel også forskelligt udseende, ved at kontrollere hvilken hardware (mobil, tablet, pc) der tilgåes fra?
//undskyld hvis jeg spørger for meget, jeg fornemmer bare at du har styr på lortet, så vil suge alt det jeg kan! :)
#11
De sidste gange jeg har arbejdet med 3 tier web applikationer, så har det været som følgende.
HTML5 præsentations tier med HTML, JS og CSS til at styre det visuelle. Med JavaScript laves der dynamiske kald til en webservice (logik tier) hvor JSON er blevet brugt som data encapsulation. Denne service kan være lavet i f.eks. PHP. Gennem data access layer på webservicen forbindes der til databasen (data tier).
Her kan præsentations tier være hosted på server A, logik tier være hosted på server B og database på server C.
Hvis der som beskrevet bliver brugt JSON til data transport, så kan man f.eks. også sætte mobile apps til at hente fra selvsamme logik tier.
De sidste gange jeg har arbejdet med 3 tier web applikationer, så har det været som følgende.
HTML5 præsentations tier med HTML, JS og CSS til at styre det visuelle. Med JavaScript laves der dynamiske kald til en webservice (logik tier) hvor JSON er blevet brugt som data encapsulation. Denne service kan være lavet i f.eks. PHP. Gennem data access layer på webservicen forbindes der til databasen (data tier).
Her kan præsentations tier være hosted på server A, logik tier være hosted på server B og database på server C.
Hvis der som beskrevet bliver brugt JSON til data transport, så kan man f.eks. også sætte mobile apps til at hente fra selvsamme logik tier.
#11
re skalering)
Du kan godt tilføje flere app servere.
Hvis du har 2 servere med både frontend og backend og du har brug for at fordoble kapaciteten, saa er det ret oplagt at gå til 4 servere med både frontend og backend.
Men skal di fordoble kapaciteten endnu en gang så skal du overveje:
- 4 servere med frontend
- 4 servere med backend
fremfor:
- 8 servere med frontend og backend
Af flere grunde:
* det er ikke sikkert at kapacitets behovet stigers ens for frontend og backend
* hvis frontend serveren skal snakk sammen og backend serverene skal snakke sammen (shared state) så stiger overheadet ved dette mere end lineært med antal servere
* driftsmæssigt er det nemmere at identificere fejl
re skalering)
Du kan godt tilføje flere app servere.
Hvis du har 2 servere med både frontend og backend og du har brug for at fordoble kapaciteten, saa er det ret oplagt at gå til 4 servere med både frontend og backend.
Men skal di fordoble kapaciteten endnu en gang så skal du overveje:
- 4 servere med frontend
- 4 servere med backend
fremfor:
- 8 servere med frontend og backend
Af flere grunde:
* det er ikke sikkert at kapacitets behovet stigers ens for frontend og backend
* hvis frontend serveren skal snakk sammen og backend serverene skal snakke sammen (shared state) så stiger overheadet ved dette mere end lineært med antal servere
* driftsmæssigt er det nemmere at identificere fejl
#11
re forskellige frontends)
Hvis vi snakker PC vs tablet vs mobil, så er der to tilgange:
* et presentation layer og RWD
* flere presentation layer (typisk er for PC+tablet og et for mobil)
Hvis det sidste laves pænt så kan de to naturligvis køre på forskellige servere.
re forskellige frontends)
Hvis vi snakker PC vs tablet vs mobil, så er der to tilgange:
* et presentation layer og RWD
* flere presentation layer (typisk er for PC+tablet og et for mobil)
Hvis det sidste laves pænt så kan de to naturligvis køre på forskellige servere.
#12
Det er moden indenfor web applikationer idag.
Jeg vil kategorisere den som:
3 tier:
* client tier
* application tier
* database tier
3 layers i application tier:
* service layer
* business logic layer
* data access layer
2 layers i client tier:
* presentation layer (HTML, CSS)
* application layer (JS, JS libs)
Det er moden indenfor web applikationer idag.
Jeg vil kategorisere den som:
3 tier:
* client tier
* application tier
* database tier
3 layers i application tier:
* service layer
* business logic layer
* data access layer
2 layers i client tier:
* presentation layer (HTML, CSS)
* application layer (JS, JS libs)
Endnu en grund til at opdele frontend og backend kunne være, at der er brug for en API, som eksterne udviklere kan integrere med.
Man kan lave et design, hvor eksterne udviklere kan kommunikere direkte med backend uden at gå gennem frontend.
Fordelen ved en sådan direkte kommunikation er, at man ikke så nemt kommer til at lave en mangelfuld API. Alle API kald, som var nødvendigt for at implementere ens egen frontend vil naturligvis være til stede i backend.
Ulempen er at man måske ikke har været så omhyggelig med sikkerheden i en API, som man i første omgang troede kun skulle kaldes fra ens egen frontend. Men uanset om man har tænkt sig at gøre backend API direkte tilgængelig eller ej, så er det en god idé at gennemgå sikkerheden i den så omhyggeligt, som man ville gøre med en offentlig tilgængelig API.
Man kan lave et design, hvor eksterne udviklere kan kommunikere direkte med backend uden at gå gennem frontend.
Fordelen ved en sådan direkte kommunikation er, at man ikke så nemt kommer til at lave en mangelfuld API. Alle API kald, som var nødvendigt for at implementere ens egen frontend vil naturligvis være til stede i backend.
Ulempen er at man måske ikke har været så omhyggelig med sikkerheden i en API, som man i første omgang troede kun skulle kaldes fra ens egen frontend. Men uanset om man har tænkt sig at gøre backend API direkte tilgængelig eller ej, så er det en god idé at gennemgå sikkerheden i den så omhyggeligt, som man ville gøre med en offentlig tilgængelig API.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund