1주차와 같은 요구사항과 기획서 기반으로 개발하였다.
🚨3주차 때 주요하게 봤던 것
- 코드컨벤션
- view,Controller,service,repository 각 계층에 대한 역할이 명확하게 구분되어있고 서로의 영역에서 알아야할 정보들만 알고 있는가?
- mybatis 사용과 설정으로 가져가는 이점
- spring boot사용으로 얻는 이점
(각 계층의 의존성을 명확하게 분리할 수 있었다./webapp프로젝트를 만들 때 해야하는 설정에 대해서 정말 간단하게 해결 할 수 있음 ex)내장 톰캣과 spring 속에 들어가있는 라이브러리 , 따라서 개발에 더 집중 할 수 있는 환경이 만들어졌다.)
🚨사용 기술
언어는 java11, mariaDB sql, javascript
프레임 워크는 Spring boot 2.7.8 , mybatis
템플릿 엔진은 thymeleaf
🚨계층 구성
전체적인 흐름은 view - controller(view에 따른 클래스 분할) - service(화면과 행동에 따른 클래스 분할)(지금보니 약간 뒤죽박죽으로 구성한거 같기도 하다) - repository(행동에 따른 인터페이스 분할)을 하였다.
예를 들면 List 페이지를 들어가면 여러 행동을 해야한다. 이 행동을 controller가 List서비스에서 해당되는 로직들을 이용하여 구현한다.
(ListService에 들어있는 로직들)
1. 검색조건 창에 카테고리를 고르는 영역에서 카테고리의 목록을 받아온다.
2. 페이징을 구성한다.
3. 검색조건에 맞는 게시글 목록을 불러온다.
게시글 작성 페이지를 보여주는 기능과 등록에 대한 기능은 분리한 이유:
처리의 흐름상 다른 영역으로 판단했다.
게시글 목록 보여주기 > 게시글 작성 > 등록 이런 식으로 넘어간다면 명확하게 분리 되는 것이라 판단함
🚨코드 리뷰 및 피드백
- 글자수를 유효성 체크할 때 용량 문제로
글자를 byte수로 체크하려면 한글은 바이트가 큰데 이를 어떤 방법으로 할까 고민하기
- 패키지 명은 소문자로 언더바 없이 구성하면 좋겠다.
- xml파일에서 <,>해당 기호들을 사용하지 못하는데 mybatis등등 xml 파일 사용 할 때 cdata 사용해서 <,> 해당 기호들을 사용하자
- checked exception 과 unchecked exception
차이점 언제 활용해야하는지 확인하자이것은 내가 예외 처리를 다 controller 부분에 몰아넣어서 궁금해서 피드백을 부탁드렸다. 정책에 따라서 다르지만 예외를 떠보내서 서버단에서 커스텀해 처리하게끔 하는 것이 좋다고 하셨음.
- controller를 업무 도메인으로 묶어라!
이 부분에 대해서는 장단점을 찾아보았다.1. 화면기준으로 controller를 구성했을 때 이점 -> 구조를 설계할 때 쉽게 이해할 수 있다. 2. 업무(비즈니스,행동) 기준으로 controller를 구성 했을 때 이점 -> 비슷한 기능별로 controller에 묶어서 유지보수 측면에서 장점을 가진다. but 현재 만드는 게시판에서는 많은 기능이 있지를 않다 보니까 어떤 기능으로 묶어야 할지 모르겠다.
- DTO 매핑에 대해서 고민하자 - (문제가 생겼을 때 우회하는 방법을 생각하지 말고 정통으로 효율 적이게 갈 수 있는 방법을 계속 고민하고 또 고민하자)
사실 spring에 대해서 배웠지만 사용 방법을 올바르게 알지 못해서 이런 일이 생겼다.
view에서 받는 데이터를 string으로 받다보니 db와는 타입이 안맞아 비효율적이게 DTO를 두개나 둬버렸다.
이를 DTO하나만 사용해서 옮길 방법을 챙겨라
- 페이징에 대한 인터페이스를 따로 뽑아서 검색조건과 함께 정리한다.
검색 조건은 페이징하고 함께 목록을 조회할때만 사용 될 거 같다고 하셨다.
따라서 둘은 비즈니스 적으로 하나의 묶음으로 봐보라고 하심
- 카테고리 같은 메타성 데이터는 캐시를 가지고 이용한다. spring도 제공함
카테고리에 대해서 이용할 때 마다 DB에 접근하고 DB에서 불러오는게 나조차도 비효율적이라고 생각했다.
좋은 피드백!
- 개인적으로 타임리프를 처음 써보니까 모르는 부분이 많다.
?타임리프 파일플래그? 알아보기
- mapper xml쿼리에도 목적 정도는 간단하게 적어놓자
복잡한 쿼리는 보면 이해하는데 시간걸림 배려하자.
- 파일 업로드 다운로드 구현시 path 같은 것은 하드 코딩보다 yml이나 properties같은 데에서 받아서 사용하는게 좋음 (동적으로 변할 수 있는 요소이기 때문에)
- 서비스를 트랜잭션의 단위로 구성하기
(당연한듯 어려운 것 같이 묶여서 이뤄지고 취소되어야하는 로직들 현재 게시판에서도 이런 소요가 있는지 만들면서 확인 해봐야겠다.)
일단 흐자