[데브 캠프] 3일차 회원가입을 구현하며 배운 것

1. Column 생성 시, length를 지정하되 예상보다 넉넉하게 지정한다. 

• 혹시라도 들어올 수 있는 긴 문자열을 방지하기 위함. 
• phoneNumber의 경우, 11~13자리 정도가 필요하겠지만 length를 50정도로 지정한다. 
• db schema를 나중에 변경하기 어렵기 때문. 

 

2. User entity 컬럼 중 isPersonalInfoVerified는 boolean 타입이며 개인 정보가 확인되었는지 표시하는 컬럼이다. false면 0, true면 1로 표기된다. 

 

 

3. 현재 예시 코드에서는 user와 admin을 role이 나뉘어 있다. 이를 어떻게 관리하는 것이 좋을까?

 

방안 1) 모든 회원을 user repository에서 관리하되, role 컬럼을 추가하여 user인지 admin인지 구분한다. 

• 단순하고 구현하기가 쉽다. 
• 한 개의 repository로 모든 걸 관리하기 때문에 리소스가 절약된다. (정말 그럴까? 이는 직접 구현해 봐야 정확히 알 수 있을 것)
• 사용자 역할이 추가될 경우 column에 새롭게 넣기만 하면 된다. 
• 만약 user와 admin 회원가입 시 갖게 되는 정보가 매우 다르다면 null 값이 들어가는 경우가 매우 많아질 것이다. 
• 또한 user가 admin 페이지에 들어가는 경우가 생길 수 있다. 예를 들어, role이 null일 경우, admin 권한으로 인식한다든지… 이런 상황을 방지하기 위해 로직을 더욱 신경써야 한다. 

방안 2) controller부터 service, entity, repository를 모두 분리하여 관리한다. 

• 구현하기 어렵다. 
• 대신 각 role이 하는 활동이 깔끔하게 분리되며 요구사항에 맞춰 시스템을 최적화할 수 있다.  
• role이 갖는 정보와 활동이 많이 다를 경우 이 방법이 더 적합할 것이다. 

방안 3) 역할에 중요도를 부여하여 관리한다. 

• 만약 user가 0이고 admin이 3일 때, 그 사이에 룰이 더 많아진다면 곤란해짐. 즉 확장성이 떨어진다. 
• 왜 user가 0이고, admin이 3인지도 설명하기 어렵다. 
• 그러나 각 역할마다 세분화하여 관리가 가능하다. 
• user가 0, admin이 100이면, 확장성 넘치게(?) 관리 가능하지 않을까? 

 

선택한 방법) 방안1

• 서비스적인 부분이 현재 명확하지 않아, 가장 간단하게 구현이 가능한 방안1을 선택.
• Role을 추가하기만 하면 되기 때문에 확장성도 높음. 
• 그러나 user와 admin이 아주 다른 값을 갖게 될 경우 방안2나 3으로 리팩토링하는 것을 고려해야 함. 

 

4. implementation 'org.springframework.boot:spring-boot-starter-validation’을 추가하면 값 검증이 가능하다. 

잘못된 값이 들어올 경우 controller에서 바로 내보내는 것이 가능하다. 

@NotEmpty	NULL 체크 및 문자열의 경우 길이 0인지 검사
@NotBlank	NULL 체크 및 문자열의 경우 길이 0 및 빈 문자열(" ") 검사
@Length(min= , max=)	최소, 최대 길이 검사
@Email	이메일 형식인지 검사
@Max(숫자)	지정한 값보다 작은지 검사
@Min	지정한 값보다 큰지 검사
@Null	값이 NULL인지 검사
@NotNull	값이 NULL이 아닌지 검사