[Refactoring] 22.08.04. 마이 페이지 (정보 수정, 탈퇴)

프로필 편집 Modal

구성

1. 회원 정보 수정

• 회원이 보이는 프로필 이미지를 변경할 수 있다. 클릭하면 이미지를 업로드할 수 있다.
• 회원이 사용하는 이름과 휴대전화 번호, 관심 태그 내용을 변경할 수 있다.
• 정보 수정 버튼을 눌러서 내용을 수정한다.

2. 비밀번호 변경

•  기존 비밀번호와 새 비밀번호를 입력해서 비밀번호를 변경할 수 있다.

3. 회원 탈퇴

• 회원 탈퇴를 할 수 있다.

 

코드 뜯어보기

UsersController.java

• info

 마이 페이지 이동 요청에 대한 controller의 method 이다. 매개변수를 다양한 방식으로 가지고 있는데, 차례차례 뒤져보도록 하겠다.

 

 우선 UsersService의 logic이다. 이미 session scope에 접속한 email 정보가 없으면 다시 로그인하게끔 되어있는 것으로 알고 있다. 게다가 이 페이지를 오기 위해서 보여지는 navigation bar의 '마이 페이지' 버튼도 email 정보가 없으면 볼 수 없는 항목이기 때문에, 여기에서까지 email이 null 인지 아닌지를 체크하는 것은 반복적인 logic이라고 생각해서 지워주었다.

 

 StoreServie의 logic이다. 이건 필자가 맡았던 부분인데, 기존에는 Session의 email을 기반으로 매장 정보를 관리하기 위해 개설한 매장의 정보를 list로 받아올 수 있도록 만든 method이다. 그렇게 받은 List 객체를 Map 객체에 넣어 front로 return 해주는 방식을 채택했었다.(새로운 매장 정보를 개설하는 경우, 새로 고침 없이 즉각적으로 화면에 반영될 수 있도록 ajax request를 보내고 받는 방식을 선택한 것이다.)

 정보를 session에 또 다시 기록해서 이 list 정보를 유지할 필요성이 있을까 싶지만, 매장 관리하는 기능을 구현하는 것에 있어서 경로요청을 할 때마다 계속해서 list 정보를 넘겨주는 것이 번거로워서 이런 식으로 작성했던 것으로 기억한다. Session에 관리하는 것이 좋지 않다고 생각해서 추후 지워야 할 부분이 될 것 같다. 이후 매장 관리 파트를 확인하면서 최종적으로 수정이 이뤄질 것이다. UsersController 바로 다음이 StoreController이다.

 

 OrderSerivce의 logic이다. 주문 내역을 가져오는 logic 중에 paging 처리를 위한 logic이다. 문제가 되는건 이 사이에 있는 별점 관련된 logic이다.

 

 Logic을 간단히 설명하자면 로그인 한 계정으로 주문했던 내역을 list로 불러와서, 각 주문에 대한 DB 번호를 기반으로 해당 매장의 평균 별점을 가져오고, 해당 매장에 준 나의 별점 정보를 가져오는 logic이다.

 DB 설계를 치밀하게 하지 못하고, 개발하는 중간에 계속해서 DB의 구조를 변경하고 추가하는 바람에 덕지덕지 기우는 코딩을 진행했었다. 그때 필자의 아이디어였지만, DB에 따로 review exist column을 만들었다. 이건 명백한 필자의 잘못이다. 해당 내용을 DB에 넣을 것이 아니라 select query를 통해 dto에 review 존재 여부를 setting 했으면 좋았을 것 같다. 이렇게 DB 관련된 내용은 모두 SpringBoot로 바꿔보기 전 DB와 객체 설계를 치밀하게 하면서 다시 손 보겠다.

 

• getUser

 별다른 수정하고싶은 부분이 없었다.

 

• update

 회원 정보를 update 하기 위한 controller의 method이다. 이곳에서도 logic의 성공 여부를 boolean으로 처리하는 것을 service logic으로 넣으려고 한다.

 

 Dao method의 return type을 void에서 int로 바꿔서 수정 여부를 확인할 수 있도록 한 뒤, front에서 성공 여부에 따라 달리 보일 수 있도록 Map 객체에 담아서 response 하는 방향으로 수정하였다. 캡쳐에는 담겨있지 않으니 사용하지 않던 HttpServletRequest 객체가 전달되던 것도 지워주었다. 또한 그에 맞게 front 단의 동작도 수정했다.

 

• ajaxProfileUpload

 마이 페이지에서 profile image를 업로드하기 위한 controller의 method이다. 단순히 image file을 업로드하는 logic일 뿐이고, 줄 변경 말고는 수정사항이 없다.(Back 단에서는) Method가 대문자로 시작하는 경우가 많았는데, AOP를 적용하려다가 그만 둔 흔적이 아닐까 생각해본다.

 사실 이 기능은 front에 작성된 부분에서 이미지를 선택하는 즉시 업로드가 진행된다는 문제가 있다. 이에 관해서는 필자가 매장 관리 파트에서 즉시 업로드되지 않도록 작성한 부분이 있는 것으로 기억하는데, 그때 다시 살펴보도록 하겠다.

 

• pwdUpdate

 비밀번호를 변경하는 controller의 method이다. update method와 마찬가지로 단순히 줄바꿈만 해주었다. 관련 수정 사항은 service 단의 updateUserPwd method에 있다.

 

 Dto 객체에 기존의 password에 더해서 새 password를 담을 newPwd field를 만들어서 dto로 data를 받아 비교하고, DB의 pwd 자리에 newPwd 값을 넣어주는 logic이다. Front 단에 'email' 이라는 이름으로 값을 사용하는 것이 없음에도 전달하고 있어서 해당 부분을 없애주었다. 더해서 성공 여부에 대한 정보도 함께 return 하는데, 이에 대한 response가 따로 없어서 front 단에서 경우의 수를 나눠주었다.

 

• getOrderUser

 놀랍게도(?) 동일한 logic을 서로 다른 method로 만들어두었다. 같은 dao method를 사용한 것이지만, 하나는 login 된 아이디로, 다른 하나는 전달받은 email data를 통해 DB에서 정보를 받아오는 logic이다. 따로 건들지는 않으려고 한다.

 

• delete

 회원 탈퇴를 위한 controller method에서 logic을 직접 처리하고 있는 부분을 목격하였다. 해당 logic은 service 단으로 옮겨주어야 할 일이다. 아마 기억상, 유저의 정보를 지우면서 동시에 유저가 만든 가게 정보와, 주문했던 내역을 모두 지우기 위한 항목이다. 일단 아무래도 DB 설계부터 꼬여있는지라 상당히 복잡한지라 당장은 DB에 손 대기가 꺼려지지만, DB에 대한 문제는 이 project의 back 부분을 Spring Boot로 변신시키면서 해결해보겠다.

 

 일단 있는 logic부터 servie 단으로 옮겨주기로 했다. 한 계정으로 여러 상점을 관리할 수 있어서 해당 상점 목록들을 모두 지울 수 있도록 for문을 사용해 삭제하는 과정을 service 단에서 하나의 method로 통합해주었다. 그 과정에서 아무런 정보를 받지 않아서 전달받는 StoreDto 객체를 지워주었다. 이와 관련된 연결되는 StoreController의 method에서도 전달하는 StoreDto를 지워주었다.

 

 여기에서도 삭제 성공 여부를 파악해야할 것 같다. 그래서 dao method의 return type을 int로 바꿔주었다. 그리고 해당 작업의 성공 여부를 함께 Map 객체에 넣어 전달했고, 이를 front 단의 info.jsp 에서 받아서 경우의 수를 나누어 response 할 수 있도록 했다. 여기에서 주의할 점은 mapper xml file에서 resultType을 int로 설정해주는 것은 아니라는 것이고, 단순히 method의 return type을 void에서 int로 바꿔준다.

 

 

info.jsp

 

 

참고 : https://github.com/Gyuhwan-Kim/TheSeat

GitHub - Gyuhwan-Kim/TheSeat: Past Project Reboot