[스프링부트] 글 목록 보기 View 렌더링

익명 블로그 V1 - 8

Nov 18, 2024

Contents

[익명 게시글을 쓰는 블로그 만들기 8]BoardController 클래스 - 매핑 BoardService 클래스 - 게시글목록보기() 메소드 list.mustache 파일 - 게시글 목록 보기 View 웹에서 실행 request 객체에 대한 이해 참고

[익명 게시글을 쓰는 블로그 만들기 8]

BoardController 클래스 - 매핑

Model을 파라미터에 넣고 GetMapping에 활용 ⇒ DS

request객체를 model이라는 객체로 랩핑(포장)해서 전달

Board 클래스의 정보를 넣는 List를 활용하려는 코드가 별로 좋지 않은 코드인 이유?

게시글 목록 띄우기에 쓸데없는 정보도 들고오기 때문
DTO 클래스를 만들어서 DTO의 정보를 넣는 List로 바꿔서 해결하면 코드가 깔끔해질 수 있음


package com.example.blog.Board;

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

import java.util.List;

@RequiredArgsConstructor // final이 붙어있는 필드에 대한 생성자를 만들어줌
@Controller
public class BoardController {

    private final BoardService boardService;

    @GetMapping("/") // get 요청
    public String list(Model model) { // DS(request객체를 model이라는 객체로 랩핑(포장)해서 전달)

        // 별로 안 좋은 코드인 이유?
        // => 게시글 목록 띄우기에 쓸데없는 content와 created_at도 들고오기 때문
        List<Board> boardList = boardService.게시글목록보기();
        // "models" => request의 키값
        model.addAttribute("models", boardList);
        
        // 파일명만 적어놓으면 view resolver가 .mustache파일을 templates에서 찾아냄
        return "list"; // view
    }
}

BoardService 클래스 - 게시글목록보기() 메소드

BoardRepository 클래스의 findAll() 메소드 반환


package com.example.blog.Board;

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

import java.util.ArrayList;
import java.util.List;

@RequiredArgsConstructor // final이 붙어있는 필드에 대한 생성자를 만들어줌
@Service
public class BoardService {

    private final BoardRepository boardRepository;

    public List<BoardResponce.DTO> 게시글목록보기() {
        
        return boardRepository.findAll();
    }
}

list.mustache 파일 - 게시글 목록 보기 View

{{ }} : java jsp에서의 el(${})과 같음

#순회할대상 : mustache파일에서의 for-each문, 이 경우 models를 순회

models는 BoardController에서 지정한 request의 키값(순회할 게시글List)

{{ }}로 표의 바디에 게시글의 번호와 제목을 들고옴


<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>blog</title>
</head>
<body>

<nav> <!-- 헤더가 네비게이션 역할을 할거니까 -->
    <ul> <!-- 헤더 -->
        <li>
            <a href="#">홈</a>
        </li>
        <li>
            <a href="#">글쓰기</a>
        </li>
    </ul>
</nav>

<hr> <!-- 줄긋기 -->

<section>
    <!-- 표 -->
    <table border="1"> <!-- border로 테두리 설정 -->
        <tr>
            <!-- 표의 헤더 -->
            <th>번호</th>
            <th>제목</th>
        </tr>

        <!-- #순회할대상 : mustache파일에서의 for-each문, 이 경우 models를 순회 -->
        <!-- models는 BoardController에서 지정한 request의 키값(순회할 게시글List) -->
        <!-- 겹중괄호는 java jsp에서의 el(${})과 같음 -->
        {{#models}}
        <tr>
            <!-- 표의 바디 -->
            <td>{{id}}</td> <!-- 게시글 번호 가져오기 -->
            <td>{{title}}</td> <!-- 게시글 제목 가져오기 -->
            <!-- 상세보기를 클릭하면 해당 글의 id에 맞는 정보가 담겨진 상세보기 화면이 보여짐 -->
            <td><a href="/board/{{id}}">상세보기</a></td>
        </tr>
        {{/models}}
    </table>
</section>

</body>
</html>

웹에서 실행

request 객체에 대한 이해 참고

Tomcat의 scope - was (저장 자료 구조)

server

request

기본 원리

외부에서 클라이언트가 was한테 요청을 하면 was가 통신으로 버퍼에 클라이언트의 정보, 클라이언트가 들고오는 데이터(Http Header와 Body)를 문자열로 담아서 객체로 만듦

request 객체와 문자열로된 데이를 합쳐서 값이 들어간 request로 만듦

값이 들어간 request 객체를 스프링에게 넘기면 라우팅(Dispatcher Servlet(url을 받아서 찾아줌))이 request 객체를 먼저 받음

클라이언트에 request 객체로 응답

request 객체는 was에 들어왔을 때 만들어졌다가 응답으로 was에서 내보내지면 사라짐

request에 저장할 때 더 좋은 이유

클라이언트가 Tomcat을 통해서 Dispatcher Servlet에 요청하면 request 객체가 만들어짐

Dispatcher Servlet은 메소드를 통해 Controller에 요청

Controller와 Service, Repository 작동 ⇒ Model(DB에서 조회된 데이터들)을 돌려줌

Model을 View에 합쳐서 응답하는데 이 때 저장해야 할 곳 ⇒ session 또는 request

session에 저장하면 안 사라져서 서버에 부하가 크기 때문에 좋지 않음
request에 저장하면 사라질 수 있어서 서버에 부하가 적어서 적절함

Model을 request 객체에 담음 → 템플릿 엔진(jsp, mustache 등)에서는 request 객체에 담겨있는 Model을 꺼내서 뿌림

이 때 Spring을 이용한다면 Spring이 request 객체에 넣지 말고 Model이라는 객체를 만들어줄테니 그곳에 넣으라고 함 ⇒ 그런데 그 Model의 본질은 어차피 request 객체 (저장할 곳이 request 밖에 없기 때문)