[2주차] 고민중인것들...

1. 등록 , 수정 화면을을 합쳐서 사용할지 Or 나눠서 사용할지에 대해서 

 

처음 프로젝트 설계를 할 때에 들던 생각은 생성과 수정은 비슷한 메커니즘을 가진다는 생각에 합쳐서 사용하기로 결정했다.

회원 등록 및 수정 기능을 개발하면서 처음 부딛힌 난관은 '1개의 뷰 템플릿이 어떤 분기점에서 생성 페이지가되고 수정 페이지가 되느냐' 였다.

그 해답으로

1. 회원의 ID가 넘어올 경우 -> 회원의 ID를 조회한 뒤 수정 처리

2. 회원의 ID가 넘어오지 않을 경우 -> ID가 null이니 자연스럽게 비어있는 memberDto를 넘겨 등록 처리

 

로 개발을 진행했지만...

 

회원 정보 수정시에 수정하면 안되는 필드값들을 readOnly 처리를 해야되서 타임 리프의 th:if를 사용해 두개의 input tag를 만들어 너무 지저분하고 복잡한 HTML 작성됬다.

 

이 때 부터 슬슬 고민이 시작됬다. '등록과 수정 화면을 하나로 합치는게 과연 효율적인 방식일까?'

 

본격적으로 고민을 시작하게 된 트리거는 데이터 검증처리에대해 배우면서였다. 

당장 진행하고있는 나의 팀프로젝트는 매우 단순하고 쉬운 수준의 프로젝트지만 실제로 운영되고있는 웹사이트들은 생성과 수정시의 검증 방법이 각각 다른 형식을 가지고있다. 

 

예를들어 생성에는 당연히 id값이 필요없지만, 수정에는 hidden으로 id값을 숨겨받아 id를 반드시 넘겨야 한다던지의 등록과 수정의 검증 차이가있다.

이렇게 등록과 수정 페이지를 하나로 합치는데에 큰 단점만 느껴지고있는 상황에서 회원 등록과 생성 템플릿을 두개로 나누는데에 마음이 쏠리고있지만 게시물 작성같은 경우엔 한개의 템플릿으로 합쳐 사용하는것이 아무리봐도 효율적인것같아 공지사항같은 단순 게시판 같은 경우는 그대로 하나의 템플릿 방식으로 갈지 고민중이다...

 

 

2. 현재 나의 팀 프로젝트의 DTO 설계 방식이 맞는건가

 

현재 inner static class를 이용하고있다.

 

xxxDTOs 라는 Class에 request와 response 두개의 inner static class 를 사용하고 있다. 

이 방식으로 설계하게된건.. 프로젝트 초기 설계단계에 팀원과 어떻게 프로젝트 구조를 만들지에대해 많이 고민했고 깃허브에서 다른사람들은 어떻게 프로젝트 구조를 설계했는지 찾아봤다.

 

여러가지 구조가 많았지만 가장 눈에 띄인건 위와같이 inner static class를 이용한 방식이였다. 

저 방식을 차용한 이유중 가장 큰 이유는 부끄럽지만 깔끔하고 간편해보여서였다. 

 

프로젝트를 진행하면서 다른사람들의 코드들도 더 보고 강의도 들으면서 

Layerd Architecture 에 대해 더 공부하게 됬는데

현재 나의 dto 방식으로 돌아가는 프로그램은 Presentation 계층의 requestDTO 클래스를 Service 계층이 의존하고있다는 문제점이다. 

책임의 분리라는 점을 고려했을때 각 계층은 서로 협업하되 다른 계층에 의존해서는 안되기에

프로젝트를 진행하면 진행할수록 현재 나의 프로젝트 구조에대해 뭔가 큰 아쉬움이 든다.

 

물론 혼자서 진행하는 프로젝트라면 수고스럽더라도 다시 고치고 진행했겠지만 팀프로젝트인만큼 팀원과의 상의도 필요하고 조율이 필요하기에 이 부분은 문제점을 알았지만 당장 해결할 순 없고 추후에 개인 프로젝트를 진행할때 반영해서 구조를 설계하기로 결정했다.

 

 

마지막으로 프로젝트를 진행한지 3주정도가 됬는데 생각보다 진행상황에 더뎌지는 점이 아쉽고 

오류나 문제를 발견할때마다 정리해서 블로그에 올려두고싶은데... 그게 참 어렵다... (문제 해결당시에는 정신없이 해결하고 해결한뒤에는 신나서 정리할 생각이 안들었다.)

 

앞으로라도 좀 더 알게되고 해결한부분들을 정리해서 다음 프로젝트때는 같은 실수를 반복하지않고 다시 만나게되는 문제에 당황하지않고 해결하도록 노력해야겠다.