고객 지원 게시판 제작을하며 팀원과 공지사항은 상단에 항상 고정되있는 방식으로 설계를 진행했다.
원래 고객 지원 게시판 개발은 다른 팀원이 맡아 개발하고 있었지만 같이 고생하는 팀원이나, 팀장인 본인이나 아직 웹개발에 서툰 부분도 많고
아무래도 혼자 진행하기에 벅찬 분량이기도해서 페이징 처리는 내가 맡기로 했다.
일단 최종 결과로 나오게 된 게시판 형태인데 처음에 설계했던 방식 그대로 구현되어 참 다행이다라고 느꼈다
진행하면서 페이징 처리 기능을 구현하면서 어려움이 있었는데...
일반적으로 학원에서 배운대로 페이징 처리를 진행했더니 공지사항 게시물이 맨 마지막페이지에 몰려버렸다....
View Controller에서 한개의 page collection에 공지사항과 일반 게시물을 같이 담아 보냈더니 위와같은 의도치 않은 상황이 발생됬고
팀원과 급하게 디스코드로 논의해 모델을 두개로 만들어 따로 담아 보내기로 했다.
우선 JPQL을 이용해서 Board Entity에서 게시물의 타입에 따른 리스트를 구했다.
Service 계층에서 공지사항이냐 일반 게시물이냐에 따라 두가지 메서드가 필요했다.
공지 사항같은 경우는 항상 상단에 고정되어 있어야하기 때문에 페이징처리가 필요하지 않다.
(처음에 이걸 모르고 페이징처리를 같이해버려서 공지사항이 항상 페이지 맨 마지막에 짱박혀있었다.)
하지만 일반 게시물같은 경우는 페이징 처리가 필요해 따로 메서드를 작성해줄 필요가 있다.
View Controller에서 총 3개의 모델을 보내기로했다.
1. 공지사항의 List<BoardResponseDTO>
2. 일반 게시물의 Page<BoardResponseDTO>
3. 현재 페이지값을 넘겨주기위한 단순 page int 값
HTML 페이지에서 모델을 출력할 div 영역을 두개로 만들어 각각의 영역에 공지사항, 일반 게시물의 데이터를 뿌려줬다.
(처음엔 모델을 두개 넘기는 방식이 맘에들지않아 한개의 모델을 담아보내 타임리프의 th:if 를 사용해 따로 받아보려했지만 한개의 모델만을 보냈을 경우 공지사항의 상단 고정이 구현되지 않았다...)
어찌저찌 공지 사항 상단고정에 성공했다.
이번에 페이징처리를 하면서 느낀점은
첫번째로, 내가 작성하지않은 코드를 기반으로 새로운 기능을 추가하려니 그 점이 너무 힘들었다..
혹시 어딘가를 내가 수정했을 때 어떤 사이드 이펙트가 발생할지 모르기때문에 조심조심하며 코드 작성을 했었고,
내가 짠 코드 역시 다른 누군가가 그 위에 다른 기능개발을 위한 코드작성이 필요할 때를 생각해 다른 사람이 알아보기 쉽고 편한 코드 작성이 1순위란것을 깨닳았다.
두번째로, 당장 잘 안풀리더라도 결국 해답은 존재한다 라는것을 깨닳았다.
처음 공지 사항 상단고정이 안될 때 게시물 Entity를 나누어 공지 Entity , 일반 게시물 Entity 로 2개로 쪼개야하나? 생각이 들어
이런저런 생각이 많이 들었다. 내가 기초 클래스 설계를 잘못했나 싶기도했고 엔티티를 두개로 쪼개서 다시 만들면 시간이 많이 딜레이될텐데 하며 걱정도 됬지만,
팀원과 급하게 디스코드로 토의를 하면서 JPQL로 쿼리를 따로 작성해 두개의 쿼리로 두개의 모델을 화면에 뿌려주자는 결론을 도출할 수 있게 됬다.
각각의 클래스간의 기능들의 역할과 책임을 생각해가면서 그 흐름을 다시 파악해보니 정답이 보였던 경우였다.
쇼핑몰 프로젝트에서 이제 겨우 게시판 하나를 완성한거지만 벌써부터 배우는게 참 많다..
그만큼 모르는게 많다는 의미이니까 더 열심히 해야겠다는 생각이 들고 그런다...
'Project > multiplexShop' 카테고리의 다른 글
| [3주차] 고객 지원 게시판 개발 완료 후 회고.. (0) | 2023.09.11 |
|---|---|
| [2주차] 고민중인것들... (0) | 2023.09.06 |