1주차와 같은 기획서와 요구사항을 기반으로 개발하였다.
🚨4주차 때 주요하게 봤던 것들
코드컨벤션 같은 것은 기본으로 삼는다.
🚨 4주차에 내가 하려던 목록들
- 캐시 적용 o
- mapper 쿼리문 xml에서만 하도록 변경 o
- page랑 검색조건 결합해서 하나로 사용 o
- 파일 업로드와 다운로드 기능 추가 o
- 컨버터 사용하기 o
🚨느낀점
1. 캐시 적용
카테고리나 조회수에 대해서 db에 접근을 너무도 많이 해야하는 소요가 있었다.
따라서 캐시를 이용해서 DB에는 변경사항이나 일정 조건을 가지고서 동기화 할 수 있도록 이런 부분을 고려하기 위해 캐시를 적용 시켜봤다.
캐시에 대해서 레디스 등등 여러종류가 있었지만 가장 기본적인 스프링캐시를 구현체로 사용했다.
캐시의 동작에 대해서 이해를 못하고 한 클래스 내에서 캐시를 사용하는 메소드에 대해서 사용하려다가 시간을 많이 잡아먹음
중요한 점은 캐시도 프록시를 이용해서 aop 처럼 작용 한다는 것 즉 내부에서 사용하면 this.~~ 로 사용하기 때문에 프록시가 적용되기 전에 사용되어서 캐시가 적용이 안되었다.
2. mapper 쿼리문 xml에서만 하도록 변경
간략한 매핑은 java mapper 에서 했었는데 이 또한 xml로 다 옮겼다.
확실히 쿼리문을 모아놓고 IDE에 DB연결을 해놓으니까 테이블명이나 변수명을 잡거나 오타를 잡아주는 것이
유지보수성에 좋다고 느낌
3. page랑 검색조건 결합해서 하나로 사용
사용에 대한 생명주기가 같은 조건이어서 하나로 묶었다.
확실하게 코드에 대해서 간략해짐을 느꼈지만 pagination 이라는 클래스명이나 변수 하나로 이해하기에는
2가지 기능이 합친 느낌이 들음
또한 controller에서 역할을 줄이기 위해 service층 pageSetting메소드 안에 category의 목록을 불러주는 서비스계층의 메소드를 사용해서 category의 값을 세팅하며 service 계층끼리의 사용에 대해서 고민했었다.
찾아보고 찾아본 결론은 당장 작은 프로젝트에 고정적이고 크게 변동이 없는 데이터를 사용하는 service계층은 괜찮지만
service계층끼리의 무분별한 사용은 흐름을 깨트리기에 조심해야겠다고 느꼈다.
애초에 이렇게 안되도록 설계하는게 더 좋을 거 같다.
4. 파일 업로드와 다운로드 기능
업로드는 service 계층에서 파일을 업로드하며 업로드 정보를 반환하게끔하는 메소드와 업로드 정보와 게시글 정보를 DB에 등록하는 메소드로 구성했다.
이 과정에서 MultipartFile의 값이 들어올 때 파일이 없으면 제목이 "" 이런식으로 들어온다.
처음에 파일이 있는지 없는지에 대한 검증을 isTrim을 사용했다가 size가 0인 파일에 대해서도 trim이 없다고 적용되는 것을 보고 !"".equals(filename) 이런식으로 검증을 바꾸었다.
5. 컨버터 사용하기
컨버터를 사용하면서 제일 고민했던점은 타입을 바꿀 때 service 로직이 사용되야하는 categoryName과 categoryId를 바꾸는 과정에 있었다. 아무래도 정해진 repository와 service - controller 의 흐름에서 벗어난다는 느낌이 들어서 DTO에 categoryName 속성을 추가하고 3번에서 얘기한 것 처럼 service로직끼리의 사용으로 바꾸기로 하였음
🚨앞으로 해야할 것들
- 게시글 수정과 삭제 구현
- vue.js 로 front단과 back단을 분리해서 api로 통신하게끔 만든다.
- 예외 처리와 validation 데이터에 알맞게 깨끗하게 구현
- 비밀번호 암호화 알고리즘 적용 (복호화 안되게끔)
