Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.Oppiskele Kolmitasoinen Arkkitehtuuri | Spring Bootin Perusteet
Spring Boot Backend

bookKolmitasoinen Arkkitehtuuri

Tämä tehdään, jotta erityinen logiikka voidaan jakaa eri luokkiin/paketteihin sen sijaan, että kaikki kirjoitettaisiin yhteen luokkaan.

Pyyntö käsitellään seuraavassa järjestyksessä: Controller → Service → Repository. Tämän jälkeen vastaus palautetaan käänteisessä järjestyksessä: Repository -> Service -> Controller. Aloitamme toteutuksen Repository-kerroksesta.

Repository-taso

Tämä on alin kerros, jossa vastaanotetaan käsiteltyä dataa Service kerrokselta ja tallennetaan sen tietokantaan.

Nämä luokat merkitään @Repository annotaatiolla, jotta ne lisätään Spring-kontekstiin.

Main.java

Main.java

copy

              
1234

            
@Repository
public class RepositoryLevel {
    // connect DB
}

Esimerkki repositoryn käytöstä

Palvelutaso

Tässä tapahtuu sovelluksen ydinlogiikka. Serviceissä käsitellään tai muokataan dataa ennen sen siirtämistä repository-kerrokseen.

Service-luokissa käytetään @Service annotaatiota, joka määrittelee luokan service, joka sisältää liiketoimintalogiikan.

Main.java

Main.java

copy

              
1234567

            
@Service
public class ServiceLevel {

    public void logic() {
        //TODO: write business logic
    }
}

Esimerkki servicen käytöstä

Ohjainkerros

Tämä kerros käsittelee alkuperäisen vuorovaikutuksen asiakkaan ja palvelimen välillä. Kaikki pyynnöt, jotka lähetetään asiakkaalta, saapuvat tänne, ja se on vastuussa asiakkaan toimittamien tietojen vastaanottamisesta.

Se käsittelee saapuvat HTTP-pyynnöt ja palauttaa HTTP-vastaukset. Ohjaimet toimivat "siltana" asiakkaan ja liiketoimintalogiikan välillä.

Tällä tasolla käytetään kahta annotaatiota luokan määrittämiseksi ohjaimeksi:

  • @RestController: Määrittää luokan REST-ohjaimeksi, joka käsittelee HTTP-pyynnöt ja palauttaa tiedot JSON-muodossa;

  • @Controller: Määrittää luokan MVC-ohjaimeksi, joka käsittelee pyynnöt ja palauttaa näkymiä (esim. HTML).

Main.java

Main.java

copy

              
12345678

            
@Controller
public class ControllerLevel {

    @GetMapping("/root")
    public String getPage() {
        return "template";
    }
}

@GetMapping -annotaatio määrittää URL-osoitteen tietylle pyynnölle. Tämä tarkoittaa, että lisäämme määritetyn polun /root verkkotunnukseen, ja vastineeksi saamme vastaavan sivun.

Esimerkki ohjaimen käytöstä

Videolla esiintyvä Thymeleaf-riippuvuus

Tässä on linkki Thymeleaf-riippuvuuteen Maven-repositorioon.

Mutta mitä tapahtuu, jos tätä lähestymistapaa ei noudateta?

Teknisesti ottaen ei mitään. Vaikka kirjoittaisit kaiken liiketoimintalogiikan controlleriin, yhdistäisit tietokantaan siellä ja palauttaisit vastauksen asiakkaalle samasta paikasta, kaikki toimii silti samalla tavalla.

Kuitenkin et todennäköisesti muista mitä kirjoitit sinne muutaman viikon kuluttua, koska kaikki sovelluslogiikka on yhdessä paikassa, mikä on erittäin hankalaa.

Yhteenveto

Kolmitasoinen arkkitehtuuri tarjoaa selkeän erottelun controllers-, services- ja repositories-kerrosten välillä, mikä tekee kehitysprosessista järjestelmällisemmän ja helpommin ylläpidettävän.

Jokainen kerros keskittyy omaan tehtäväänsä, mikä yksinkertaistaa sekä työnkulkua että projektinhallintaa.

Oliko kaikki selvää?

Miten voimme parantaa sitä?

Kiitos palautteestasi!

Osio 2. Luku 5

Kysy tekoälyä

expand

Kysy tekoälyä

ChatGPT

Kysy mitä tahansa tai kokeile jotakin ehdotetuista kysymyksistä aloittaaksesi keskustelumme

Suggested prompts:

Can you explain the main responsibilities of each layer in the three-tier architecture?

How does the data flow between the controller, service, and repository layers?

Why is it important to separate logic into different layers instead of using a single class?

Awesome!

Completion rate improved to 3.45

bookKolmitasoinen Arkkitehtuuri

Pyyhkäise näyttääksesi valikon

Tämä tehdään, jotta erityinen logiikka voidaan jakaa eri luokkiin/paketteihin sen sijaan, että kaikki kirjoitettaisiin yhteen luokkaan.

Pyyntö käsitellään seuraavassa järjestyksessä: Controller → Service → Repository. Tämän jälkeen vastaus palautetaan käänteisessä järjestyksessä: Repository -> Service -> Controller. Aloitamme toteutuksen Repository-kerroksesta.

Repository-taso

Tämä on alin kerros, jossa vastaanotetaan käsiteltyä dataa Service kerrokselta ja tallennetaan sen tietokantaan.

Nämä luokat merkitään @Repository annotaatiolla, jotta ne lisätään Spring-kontekstiin.

Main.java

Main.java

copy

              
1234

            
@Repository
public class RepositoryLevel {
    // connect DB
}

Esimerkki repositoryn käytöstä

Palvelutaso

Tässä tapahtuu sovelluksen ydinlogiikka. Serviceissä käsitellään tai muokataan dataa ennen sen siirtämistä repository-kerrokseen.

Service-luokissa käytetään @Service annotaatiota, joka määrittelee luokan service, joka sisältää liiketoimintalogiikan.

Main.java

Main.java

copy

              
1234567

            
@Service
public class ServiceLevel {

    public void logic() {
        //TODO: write business logic
    }
}

Esimerkki servicen käytöstä

Ohjainkerros

Tämä kerros käsittelee alkuperäisen vuorovaikutuksen asiakkaan ja palvelimen välillä. Kaikki pyynnöt, jotka lähetetään asiakkaalta, saapuvat tänne, ja se on vastuussa asiakkaan toimittamien tietojen vastaanottamisesta.

Se käsittelee saapuvat HTTP-pyynnöt ja palauttaa HTTP-vastaukset. Ohjaimet toimivat "siltana" asiakkaan ja liiketoimintalogiikan välillä.

Tällä tasolla käytetään kahta annotaatiota luokan määrittämiseksi ohjaimeksi:

  • @RestController: Määrittää luokan REST-ohjaimeksi, joka käsittelee HTTP-pyynnöt ja palauttaa tiedot JSON-muodossa;

  • @Controller: Määrittää luokan MVC-ohjaimeksi, joka käsittelee pyynnöt ja palauttaa näkymiä (esim. HTML).

Main.java

Main.java

copy

              
12345678

            
@Controller
public class ControllerLevel {

    @GetMapping("/root")
    public String getPage() {
        return "template";
    }
}

@GetMapping -annotaatio määrittää URL-osoitteen tietylle pyynnölle. Tämä tarkoittaa, että lisäämme määritetyn polun /root verkkotunnukseen, ja vastineeksi saamme vastaavan sivun.

Esimerkki ohjaimen käytöstä

Videolla esiintyvä Thymeleaf-riippuvuus

Tässä on linkki Thymeleaf-riippuvuuteen Maven-repositorioon.

Mutta mitä tapahtuu, jos tätä lähestymistapaa ei noudateta?

Teknisesti ottaen ei mitään. Vaikka kirjoittaisit kaiken liiketoimintalogiikan controlleriin, yhdistäisit tietokantaan siellä ja palauttaisit vastauksen asiakkaalle samasta paikasta, kaikki toimii silti samalla tavalla.

Kuitenkin et todennäköisesti muista mitä kirjoitit sinne muutaman viikon kuluttua, koska kaikki sovelluslogiikka on yhdessä paikassa, mikä on erittäin hankalaa.

Yhteenveto

Kolmitasoinen arkkitehtuuri tarjoaa selkeän erottelun controllers-, services- ja repositories-kerrosten välillä, mikä tekee kehitysprosessista järjestelmällisemmän ja helpommin ylläpidettävän.

Jokainen kerros keskittyy omaan tehtäväänsä, mikä yksinkertaistaa sekä työnkulkua että projektinhallintaa.

Oliko kaikki selvää?

Miten voimme parantaa sitä?

Kiitos palautteestasi!

Osio 2. Luku 5
some-alt