게시글 수정과 삭제 구현 생각보다 고민할 점이 많았고 부족한 점이 많았다.
일단 화면별로 controller와 service를 구성하면 작은 프로젝트에서는 화면에서의 흐름을 파악하기 좋지만 서비스가 커질수록 전체적인 흐름을 이해하기 힘들다. 따라서 앞으로는 도메인별로 구성 될 수 있도록 구성을 바꾸겠다.
유효성 검사는 프론트에서는 자리수만 검사하고 중요한 데이터는 서버쪽에서 비교
🚨 전체적 흐름 정리
🚨 목록 페이지
1.컨트롤러에서 uri를 받는다.
2. service
- 검색조건에 카테고리 목록을 주는 로직
- 페이지 세팅 로직
- 검색조건유지 쿼리스트링을 생성 로직(UriComponentsBuilder를 이용하여 uri와 쿼리스트링을 반환)
- 페이지와 검색조건에 따라 목록을 불러오는 로직 등 서비스 로직을 통해 화면 구성
3. repository
카테고리는 캐시를 이용하며 pagination클래스와 articles 테이블에 mapper를 통해 리스트를 반환한다.
🚨 게시글 페이지
1. controller
- 1 list에서 해당 게시글에 맞춘 uri로 넘기면 uri에서 id 식별(게시글이어도 id를 uri에 노출하는게 맞는가?) (게시글id를 외래키로 지닌 댓글과 첨부파일을 불러오게끔한다.)
- 2 uuid를 통하여 download 파일 식별하여 다운로드하게끔
- 3 댓글 등록하게끔
2. service
- 게시글 id 통해 게시글의 정보를 얻어오는 로직
- 게시글 id를 통해 첨부되어 있는 파일정보를 불러오는 로직
- uuid를 통해 file의 경로 등 정보를 불러온다.
- 게시글 id를 통해 가지고 있는 댓글의 정보들을 불러온다.
- 댓글을 등록한다.
3.repository
ArticleMapper
FileMapper
CommentMapper 이렇게 3개 사용
🚨 등록 페이지
1. controller
- 1 category 목록과 함께 화면을 보여주는 컨트롤러
- 2 등록을 할 때 유효성검사를 하고 안되면 다시 작성 페이지로 작성완료하면 list페이지로 가는 컨트롤러
2. service
- 게시글에 대한 정보를 저장하는 service로직
- 파일을 local이든 어디든 경로에 맞게 실제 저장하는 로직
- 파일에 대한 경로와 확장자,크기 등 uuid를 기본키로 저장하는 로직
(경로는 yml파일에 등록해놓고 쓴다.)3.repository
ArticleMapper
FileMapper
🚨 수정 페이지
1. controller
-1 aritcle에 대한 기본정보와 함께 화면을 보여주는 컨트롤러
-2 등록을 할 때 유효성검사를 하고 안되면 다시 수정ㄴ 페이지로 수정완료하면 list페이지로 가는 컨트롤러2. service
- 게시글 id 통해 게시글의 정보를 얻어오는 로직 (패스워드는 미포함)
- 게시글을 update하는 로직
- 게시글의 비밀번호만 불러오는 로직(비밀번호 유효성 검사를 위해)
- 첨부파일에 대한 정보들을 모두 가져오는 로직
- uuid를 통해 첨부된 파일의 정보와 실제 저장된 파일들을 삭제하는 로직
3.repository
ArticleMapper
FileMapper(해당 페이지를 구축 할 때 html에 대한 지식이 잘못된 것이 있어서 빙빙돌아 기능을 구현했다.)
(name에 다른 이름들이 들어와야하는줄 알았던 것 예를 들면 name1 name2 name3 이렇게 만들어야하는 줄 알았다. 그러다보니 동적으로 받으려고 자료구조를 사용해서 불필요하게 많은 데이터를 받고 구분해서 또 꺼내고 하는 과정을 겪었음)
🚨 삭제 페이지
1. controller
- 삭제 글에 대한 화면을 띄운 후 패스워드를 입력을 받고 유효성 검사 후 삭제하는 controller
(이 부분에서 처음 접근할때는 null일 수 밖에 없기 때문에 검사하는 if문을 추가했는데
차라리 분리하는 것이 좋은가에 대한 고민을 했었음)2. service
- 패스워드를 체크하는 로직
- articleId와 관련하여 댓글 첨부파일 게시글 다 삭제하는 로직
3.repository
ArticleMapper
CommentMapper
FileMapper
🚨피드백 받은 것
- mybatis #{}(pre~~statement) 가 아닌 ${}(statement)도
사용자가 직접 값을 넣어주는 것이 아니라
서버쪽에서 의도대로 변환해서 받을 수 있으면 보안적으로 보완 할 수 있다.
- 게시판을 종류별로 나누고 추가 했을 때 어떻게 테이블을 짤지 고민해봅시다.
- 대부분은 유효성검사는 controller 에서 해주기.
- DB에서 view에 대해서도 공부헤보기 (사용자가 직접 컬럼에 대한 직접적인 노출을 줄일 수가 있다.)
가상의 테이블로 보기에 재사용성이 높아진다.
- 조회수는 캐시는 빼는것이 좋겠다는 피드백
(유튜브같은 곳은 주기적으로 또는 규칙적으로 조회수에 대해서 캐시를 적용한다 해서 했지만)
자주 변하지 않는 데이터에 대해서만 캐시를 적용하는 것이 좋다. 피드백 받음 .
- 명확한 네이밍과 흐름을 가져가라
필요한 로직을 다 적고서 코드작성
중간에 계속 덧붙이면 복합해짐
- exception 도 무책임하게 하지말고 특정해서 해라
- 업무 도메인 묶음으로 만들기 controller
서비스도 도메인 묶음으로 만들기
- boolean 타입 다 명확하게 바꾸기
실패면 무엇이 실패인지 성공이면 무엇이 성공인지
(ArticleInputData.availableCheck() 이라는 메소드를 사용하면
이를 성공인지 실패인지 인식하기 애매한다.
변수에 담아서 명확하게 사용해주면 좋음.)
- api에서 200에 결과 실패가 오는게 맞는것인가?
비즈니스 모델에서 나오는 예외는 다 규칙을 정한 다음 상속해서 처리하기도 함
-pagenation 으로는 pagenation에 로직을 가지고 있는다.
- xml mapper 에서 where 태그 사용하기
- 파일의 저장에 대한 분류와 관리는 정책적으로 관리한다.
- postman 과 vue에서 필드의 동기화를 바로바로 시켜줘라
- category는 캐시로 해도 되고 상관없지만 지금으로는 DB에서 join으로 조회해서 얻는게 좋아보인다.
- Uri mapping 에 대해서 클래스별로 묶지 않고 메소드 각각 해준다.
나중에 봤을때 명확하게 보이지가 않음
- 페이징에서 uri랑 쿼리스트링을 만들어서 보내줄 때 페이지네이션을 사용하는 콘트롤러에 맞춰 uri는 각각의 로직에 맞게 들어가야하기 때문에 명시하면 안된다. 쿼리스트링만 만들어서 보내줄 수 있도록 바꿔라
- 동적으로 바뀌는것에 대해서 html 태그를 같은 이름으로 주자
🧑💻 해야할 일
- 위 피드백에 따라 리팩토링
- vue3로 api
