서론
서버
구조
패턴별 분석
보완 해야 되는 부분
서론
먼저 스프링에 대한 이해도, 사용 방법 모두 현저히 떨어지는 상황에서
정말 간단한 서버를 만들었고 심지어 DB도 연결하지 않은 상태이다.
글을 쓰는 목적은 정리하면서 어떻게 서버를 만들었는지에 대해 분석, 정리 하기 위해서 이다.
서버
게시글의 CRUD를 구현한 서버이다.
Create : 게시글의 생성 (제목, 작성자, 게시글 비밀번호, 내용) 필요
Read : 게시글 전체 조회,특정 게시글 ID로 조회
Update : 특정 게시글에 대해 비밀번호를 알맞게 넘기면 수정가능
Delete : 특정 게시글에 대해 비밀번호를 알맞게 넘기면 삭제 가능
API 명세서
노션링크
패키지 구조
MVC 패턴을 준수해 보기 위해 나름 분류해 봤다.
Controller
경로에 따라 들어오는 메소드별 처리를 담당
Model
entity
엔티티를 통해서 DB에서의 값을 자바의 객체로 맵핑 시켜서 다룰 수 있게 함
(현재 서버에서는 하나의 테이블만 다루기 때문에 하나의 객체만 존재)
repository
아직 실제 DB를 구현한건 아니지만 DB에 접근하여 값을 꺼내오거나 수정, 삭제등의 로직을 당담함
(현재 DB를 구현하지 못했기 때문에 HashMap으로 대체함)
DTO
데이터를 단계에 맞게 변환 시킴
구조별 분석
최대한 MVC패턴에 맞게 구현 해보기 위해 노력했다.
Controller
@RestController 어노테이션
View객체, html을 리턴하는 것이 아닌 json데이터 형식의 API관련 컨트롤러이기 때문에 위 어노테이션 사용
RequestMapping("/posts")
http://localhost:8080/posts 경로로 들어오는 요청을 해당 컨트롤러가 다룰 수 있게 맵핑
컨트롤러 부분에서는 따로 로직이 존재하지 않고 클라이언트의 요청에 따라 Model에게 일을 맡기고
그 결과에 따라 성공 여부, 응답 데이터가 필요한 경우 DTO를 통해 알맞게 데이터 응답
Model
entity
DB의 값을 자바에서 다룰 수 있게 생성자로 매핑하고 있음
값의 수정이 있을때 해당 게시글의 비밀번호와 비교하여 수정하는 간단한 로직이 존재함
해당 게시글의 비밀번호를 entity 외부에서 처리하는 것 보다 entity 내부에서 처리하는 것이 옳다고 생각해서 내부에서 간단한 로직이 돌아감
(entity 내부에 로직이 존재하는 것이 옳지 않다면 수정해야함)
interface
실제 DB와 연동시킨 것이 아니기 때문에 구현체를 바꿀 수 있게 인터페이스를 상속받아서 구현
repository
DB에서 값을 가져오거나, 수정, 삭제, 추가 등의 로직을 담당함
로직은 요청하는 게시글의 존재 여부를 판별하는 로직 존재 그 외에는 단순히 값을 넣거나 삭제하거나 수정하거나의 역할에 충실
(사실 값 넣기, 삭제, 수정등의 요청에 대해서만 작동해야 하는데 약간의 서비스로직이 들어간 것 같음)
DTO
따로 model안에 넣지 않음
JSON데이터를 dto하거나 클라이언트에게 보내기전 dto하는 모습을 보면 model에 넣어도 될 것 같지만 아직 MVC패턴에 완벽히 익숙하지 않기 때문에 별도의 존재로 여김
- 클라이언트에게서 받은 데이터를 자바로 처리하기 위해 DTO
- 처리한 자바 데이터를 알맞는 형태로 클라이언트에게 보내기 위해 DTO
보완 해야 되는 부분
- 요청에 대한 응답 상태코드 넣어봐야 함
- 실제 DB 연동
- 스프링 컨테이너에 등록하기 위한 어노테이션 정리 필요
- 테스트 코드 작성 필요
