Trelagersarkitektur
Detta görs för att separera specifik logik i olika klasser/paket, istället för att skriva allt i en enda klass.
Den ordning i vilken en förfrågan behandlas är Controller → Service → Repository. Därefter returneras svaret i omvänd ordning: Repository -> Service -> Controller. Vi börjar implementeringen med Repository-lagret.
Repository-nivå
Detta är det lägsta lagret, där vi tar emot bearbetad data från Service-lagret och lagrar det i vår databas.
Dessa klasser är markerade med @Repository-annoteringen för att läggas till i Spring-kontexten.
Main.java
1234@Repository public class RepositoryLevel { // connect DB }
Exempel på användning av Repository
Servicenivå
Här sker kärnlogiken i applikationen. I tjänster hanteras eller modifieras data innan den skickas vidare till repository-lagret.
För tjänster används @Service-annoteringen, vilket deklarerar klassen som en service som innehåller affärslogik.
Main.java
1234567@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }
Exempel på användning av tjänsten
Kontrollernivå
Detta lager hanterar den initiala interaktionen mellan klient och server. Alla förfrågningar som skickas från klienten anländer hit, och det är ansvarigt för att ta emot data tillhandahållen av klienten.
Det bearbetar inkommande HTTP-förfrågningar och returnerar HTTP-svar. Kontroller fungerar som en "brygga" mellan klient och affärslogik.
På denna nivå används två annoteringar för att utse en klass som kontroller:
-
@RestController: Deklarerar en klass som en REST-kontroller, som hanterar HTTP-förfrågningar och returnerar data i JSON-format; -
@Controller: Deklarerar en klass som en MVC-kontroller, som hanterar förfrågningar och returnerar vyer (t.ex. HTML).
Main.java
12345678@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }
@GetMapping -annoteringen specificerar URL:en för en given förfrågan. Detta innebär att vi lägger till den angivna sökvägen /root till domänen, och i gengäld får vi den motsvarande sidan.
Exempel på användning av Controller
Thymeleaf-beroendet från videon
Här är länken till Thymeleaf-beroendet i Maven-repositoriet.
Men vad händer om du inte följer detta tillvägagångssätt?
Tekniskt sett, ingenting. Även om du skriver all affärslogik i controllern, ansluter till databasen där och returnerar svaret till klienten från samma plats, kommer allt att fungera på samma sätt.
Dock är det osannolikt att du kommer ihåg vad du skrev där efter några veckor, eftersom all applikationslogik kommer att ligga på ett ställe, vilket är väldigt opraktiskt.
Sammanfattning
Trelagersarkitekturen ger en tydlig uppdelning av ansvar mellan lagren controllers, services och repositories, vilket gör utvecklingsprocessen mer organiserad och lättare att underhålla.
Varje lager fokuserar på sin specifika uppgift, vilket förenklar både arbetsflödet och projektledningen.
Tack för dina kommentarer!
Fråga AI
Fråga AI
Fråga vad du vill eller prova någon av de föreslagna frågorna för att starta vårt samtal
Awesome!
Completion rate improved to 3.45Trelagersarkitektur
Svep för att visa menyn
Detta görs för att separera specifik logik i olika klasser/paket, istället för att skriva allt i en enda klass.
Den ordning i vilken en förfrågan behandlas är Controller → Service → Repository. Därefter returneras svaret i omvänd ordning: Repository -> Service -> Controller. Vi börjar implementeringen med Repository-lagret.
Repository-nivå
Detta är det lägsta lagret, där vi tar emot bearbetad data från Service-lagret och lagrar det i vår databas.
Dessa klasser är markerade med @Repository-annoteringen för att läggas till i Spring-kontexten.
Main.java
1234@Repository public class RepositoryLevel { // connect DB }
Exempel på användning av Repository
Servicenivå
Här sker kärnlogiken i applikationen. I tjänster hanteras eller modifieras data innan den skickas vidare till repository-lagret.
För tjänster används @Service-annoteringen, vilket deklarerar klassen som en service som innehåller affärslogik.
Main.java
1234567@Service public class ServiceLevel { public void logic() { //TODO: write business logic } }
Exempel på användning av tjänsten
Kontrollernivå
Detta lager hanterar den initiala interaktionen mellan klient och server. Alla förfrågningar som skickas från klienten anländer hit, och det är ansvarigt för att ta emot data tillhandahållen av klienten.
Det bearbetar inkommande HTTP-förfrågningar och returnerar HTTP-svar. Kontroller fungerar som en "brygga" mellan klient och affärslogik.
På denna nivå används två annoteringar för att utse en klass som kontroller:
-
@RestController: Deklarerar en klass som en REST-kontroller, som hanterar HTTP-förfrågningar och returnerar data i JSON-format; -
@Controller: Deklarerar en klass som en MVC-kontroller, som hanterar förfrågningar och returnerar vyer (t.ex. HTML).
Main.java
12345678@Controller public class ControllerLevel { @GetMapping("/root") public String getPage() { return "template"; } }
@GetMapping -annoteringen specificerar URL:en för en given förfrågan. Detta innebär att vi lägger till den angivna sökvägen /root till domänen, och i gengäld får vi den motsvarande sidan.
Exempel på användning av Controller
Thymeleaf-beroendet från videon
Här är länken till Thymeleaf-beroendet i Maven-repositoriet.
Men vad händer om du inte följer detta tillvägagångssätt?
Tekniskt sett, ingenting. Även om du skriver all affärslogik i controllern, ansluter till databasen där och returnerar svaret till klienten från samma plats, kommer allt att fungera på samma sätt.
Dock är det osannolikt att du kommer ihåg vad du skrev där efter några veckor, eftersom all applikationslogik kommer att ligga på ett ställe, vilket är väldigt opraktiskt.
Sammanfattning
Trelagersarkitekturen ger en tydlig uppdelning av ansvar mellan lagren controllers, services och repositories, vilket gör utvecklingsprocessen mer organiserad och lättare att underhålla.
Varje lager fokuserar på sin specifika uppgift, vilket förenklar både arbetsflödet och projektledningen.
Tack för dina kommentarer!
