해피뉴이얼~
새해는 밝았고, 프로젝트는 오늘로 거의 마무리!
내가 맡은 도메인은 댓글 도메인 그리고 팀/멤버 도메인이다. 댓글 도메인은 뭐 익숙하니까 뚝딱하니 끝났다. 하지만 관건은 댓글을 페이징해서 보기! 다행히 팀장님이 기본 소스를 주셨다. 이를 이용해서 약간의 커스텀을 하니 페이징을 쉽게 사용할 수 있었다. 방법은 List처럼 Page도 클래스가 있었다. 이를 Pabable클래스를 이용해 설정을 해서 사용하면 됐다. 한페이지에 몇개읭 값을 담을지를 정하고, 어떤 페이지를 선택해서 조회할지를 선택해주면? 페이징 처리를 완료할 수 있었다.
두번째로는 N:N 관계를 N:1. 1:N으로 풀어주기 위해 중간 엔티티를 만들어 주기! 보드에 팀원이 N:N으로 붙어야 하는데 이를 1:N으로 풀기 위해 멤버 엔티티를 추가했다. 유저는 팀에 들어갈 때 멤버로서 들어간다. 이를 통해 유저는 여러 멤버가 될 수 있다. 그리고 멤버는 하나의 유저만 갖게 된다. 이 멤버는 하나의 팀으로 들어가게 되고, 팀은 여러 멤버를 가질 수 있다. 이렇게 유저와 팀을 N:1. 1:N관계로 풀어 버렸다. 근데 이게 생각보다 로직이 어려워진다... 왜냐하면 모든 요청은 유저로서만 들어온다. 이 유저가 어떤 팀의 어떤 멤버인지를 매번 찾아줘야 한다. 따라서 팀/멤버로 로직을 처리하게 되면 불가피하게 맞아야할 불이익은 로직(팀 레파지토리와 멤버 레파지토리를 전부 다 돌아야함)이 붙는다. 하지만 나쁜점만 있지 않다. 좋은점은 첫번째로 다대 다 관계를 풀 수 있다. 그리고, 팀마다 한 유저의 권한을 다르게 줄 수 있다. 내가 A팀에서는 멤버로서 존재한다고 해도, B팀에서는 팀장이 될 수도 있다. 이는 팀/멤버 엔티티에서는 쉽게 구현이 가능하다. 하지만 팀과 유저가 다대다 관계에 있을 땐, 이 연관관계를 맺는게 어려워진다. 왜냐하면 이런 식이면 유저는 자신의 권한을 다시 자료구조로서 가져야 한다. -> 이는 어처피 멤버를 요구한다. 아 다시 생각해보니가 트레이드 오프 관계가 아니라 필수 관계였다. 내가 만든 식으로 설계할 때는 이렇게만 설계할 수 있었던 것.
다음 프로젝트때는 좀 더 어려운 로직을 써 보고 싶다. 아직까지 테스트를 작성할 정도로 중요한 로직이 있는지 모르겠다.
