등록 페이지를 만들면서 이용되는 기술들을 다시 리뷰해보겠습니다.
앞서 목록 페이지와 상세 페이지를 만들면서 개발 순서에 대해 신경쓰게 되었습니다.
개발 순서
- 화면 완성 → 컨트롤러 → 서비스 → 리파지토리 → 리파지토리 TEST
- 리파지토리 → 리파지토리TEST →서비스 → 컨트롤러 → 화면완성
위 두 가지로 진행 될 수 있습니다. 순서는 서로 역순이지만 공통적으로 신경 써야 하는 점으로는,
각 단계 역할 분리를 통해 계층 간 의존성을 최소화해야 합니다.
각 단계마다 TEST를 통해 안정성을 확보하면서 진행해야 합니다.
코드가 읽기 쉽고 확장이 용이하도록 설계해야 합니다.
화면 완성 단계에서는 사용자가 데이터를 쉽게 이해하고 사용할 수 있도록 개발해야 합니다.
Service 기능 구현
DB에서는 게시글 등록 이지만 사용자 입장에서는 게시글을 쓰고 웹페이지에 등록되는 것처럼
보이기 때문에 메서드 명을 “게시글쓰기”로 되어있습니다.
@Transactional 어노테이션을 통해 게시글이 DB에 저장되는 것(작업)이
정상적으로 완료되면 트랜잭션이 커밋됩니다.
작업 중 예외 가 발생하면 트랜잭션이 롤백 되도록 되어있습니다.
이는 안정성을 높이기 위한 수단으로, 예외 발생 시 롤백을 통해
데이터의 무결성과 일관성을 유지할 수 있습니다.
컨트롤러 구현
컨트롤러에서 작동하는 저장 기능의 메서드입니다.
클라이언트에게 요청객체로 받아 저장하도록 하였습니다.
요청객체의 형태는 아래와 같습니다.
id는 저장될 때 자동으로 생성되고, createdAt은 저장시점의 시간으로 자동 저장되어서
SaveDto의 필드에서 제외되었습니다.
클래스로 받은 이유로는 x-www는 클래스로 요청을 받을 수 있기 때문에 요청 객체를 만들어
저장하는 방식으로 하였습니다.
화면 완성
폼의 action을 통해 버튼을 누르면 “/board/save”에 POST 요청이 가게 되고,
폼 데이터의 컨텐츠 타입으로 x-www 형식으로 가게 되어
컨트롤러에서 저장 해 달라고 요청 받은 데이터를 클래스로 받을 수 있게 됩니다.
이런 형식은 웹 1.0방식으로 insert, update, delete를 전부 POST로 처리하는 방식으로 진행했습니다.
등록페이지
참고해야 할 점
- 데이터를 전송 할 때는 무조건 form으로 감싸기
- 데이터를 보낼 때 <button>은 type=”submit”으로 설정
- 전송할 목적지 주소 적어주기 <form action=”주소”>
- HTTP 메서드 설정해주기. EX)) method=”POST”
- 보내는 데이터 컨텐트 타입 설정.
EX)) enctype=”
application/x-www-form-urlencoded" text/plain multipart/form-data
Share article