[Refactoring] 22.08.03. 로그인, 회원 가입

로그인

구성

1. 로그인 (Continue)

• 작성한 email과 password로 로그인 할 수 있다. 둘 다 필수로 입력해야하며, 그렇지않으면 버튼이 동작하지 않는다.
• 필자가 작성하지는 않았지만, test 상에서 @ 이후를 하나하나 작성하기 번거롭다며 저렇게 만들었다는 조원의 말이 생각난다.

2. 회원가입 버튼 (Signup)

• 회원가입 modal을 띄우는 버튼이다.
• 여러 사람들이 만들다보니까 어느 곳에는 한글로, 어느 곳에는 영어로 작성되어 있다.

 

회원 가입 Modal

구성

1. 회원가입 form

• 작성한 email과 password로 가입할 수 있다. 이를 포함한 이름과 전화번호는 필수 작성 내용이다. 입력하지 않으면 가입 완료 버튼을 눌러도 잘못된 항목에 대한 수정 요청을 띄운다.
• email은 중복되면 안된다. 작성과 동시에 DB에 요청해서 해당 내용이 있는지 확인 후, 일치하는 것이 있으면 가입이 불가능하도록 한다.
• password는 서로 일치해야 한다. 일치하지 않으면 가입이 불가능하도록 막았다.
• 가장 마지막 항목은 사실 필요없는 내용이다. 필수 항목은 아니다.

 

코드 뜯어보기

UsersController.java

• loginform

 로그인 form이 있는 page를 요청하는 controller의 method이다. 왜 굳이 ModelAndView 객체를 전달받아야 했는지 모르겠다. 해당 controller method의 return type을 String으로 바꿔서 return 하고, method에 전달되는 매개 변수를 지웠다.

 

• checkEmail

 회원 가입에서 email 중복 확인 check를 위한 controller의 method이다. Email을 회원 가입 form에서 작성하면, 작성과 동시에 ajax로 해당 경로 요청에 대해 Map 객체를 return 하고 있었다. 이 내용 자체에는 문제가 없고, 해당 요청을 loginform.jsp 의 이상한 곳에서 요청하고 있는 것을 발견했다. 해당 내용은 다음 다음의 login에 작성하겠다.

 

• signup

 회원 가입 요청에 대한 controller의 method 이다. Front 쪽 form의 required 속성을 사용해서 여러 에러 요소들을 열심히 막아두어서 그런지 몰라도 바로 Map 객체에 true 값을 넣어 return 했다. 혹시 모를 exception 이 발생하면 어차피 이 단계까지 오지도 않겠지만, 이렇게 바로 true 값을 넣기보다 service 단에서 중간에 check 하는 단계가 하나 들어갔으면 좋지 않았을까 싶다. 그리고 어차피 map을 return 해줄 것이었다면 이미 service 단에서 완성하는 편이 더 나았을 것이다.

 

 그래서 정상적으로 DB에 입력한 정보가 들어갔다면 query 문은 int type을 반환한다. 그래서 관련 dao method의 return type을 바꿔주어서 성공 여부를 확인하도록 했다. 그러면서 controller에서 다루는 Map을 service 단으로 가져왔다. 처음에는 insert 여부 판단을 위해 다른 service logic을 가져다가 썼는데, 사실 그럴 필요가 전혀 없다. CRUD method의 성공 여부를 파악하기 위해서는 query문을 수행하고 난 뒤 return type을 void가 아닌 int로 받으면 된다. Insert와 update, delete의 경우 해당 query 문이 정상적으로 동작하면 mybatis에서는 query문으로 수정된 colunm의 수를 반환하도록 되어있다고 알고 있다.

 사실 이렇게 하는 것보다 중간에 transaction이 들어가서, 해당 동작이 제대로 되지 않았을 경우에 대한 대비를 하는 것이 가장 좋아보이지만 일단은 이렇게 하고 넘어가려고 한다. 기억상에 transaction에 대한 작업을 하지 않았던 것 같다. 계속 살펴보면서 보완해볼 것이다.

 

• login

 로그인을 위한 controller method의 service logic이다. 보면 중복되는 logic이 존재해서 중간에 위치한 내용을 없애버렸다. 그 바로 하단의 Map 객체에도 입력한 정보를 담은 dto와 DB에서 꺼낸 dto를 모두 넣어서 return 하는데, 이를 front에서 로그인 id를 출력하기 위한 용도로 파악되어 둘 중 하나를 없애주었다. 그리고 isValemail 이라는 변수 이름도 isValid 로 수정해주면서, controller 에서 Map 에 put 해주는 logic을 service 단으로 넘겨왔다. 그리고 front에서 email을 check 하면서까지 요청을 두 번에 걸쳐 하는 것을 한 번에 줄이기 위해 login email의 존재 여부를 함께 넘기는 방향으로 수정했다.

 

 Map 으로 return한 것을 굳이 또 새로 Map을 만들어서 그 안에 넣을 필요는 없다. Map은 하나로 통일시키면서 왜 ajax 방식의 login인지를 살펴보기 위해 front 쪽을 살펴보았다.

 

 놀랍게도 front 쪽에서는 로그인을 위한 email check를 수행하고 있었는데, login 성공 여부와 별개로 login을 위한 아이디가 존재하지 않음을 알리고 싶어서 이렇게 만들어둔 것이라고 생각된다. 이것은 login에 관한 요청을 두 번에 걸쳐서 할 것이 아니라 모두 login을 위한 service logic 단에서 해결해야 할 일이라고 생각한다. (수업 당시 아무리 client side rendering을 추구하고 있다고 말했어도 말이다.)

 그래서 service 단에서 넘기도록 한 DB에 로그인 하려는 email data의 존재 여부를 가지고 다시금 if 문으로 감싸는 방식으로 바꿔주었다. 그러면서 줄을 다시 맞춰주었다. 훨씬 깔끔한 것이 속이 다 편해졌다.

 

loginform.jsp

 <script> 영역에는 위와 같은 내용이 존재한다. 해당 내용은 로그인 뿐만 아니라 회원가입에서도 적용되는 내용이다. 이 내용이 존재하는 이유는 Test 상에서 입력하기 번거롭다는 이유 단 하나 뿐이다. 때문에 이 내용을 지워버리면서 온전하게 입력할 수 있도록 바꿔야 한다. 일단 이 부분은 보류하도록 한다.

 

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

GitHub - Gyuhwan-Kim/TheSeat: Past Project Reboot