-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semina3 #3
base: main
Are you sure you want to change the base?
Semina3 #3
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
뒤늦은 코리 죄송합니다 ㅠㅠ
if (title == null || content == null) { | ||
throw new IllegalArgumentException("Title과 Content는 반드시 필요합니다."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이미 위에서 @Column(nullable = false)
처리를 했는데, 다시 한번 제목과 내용의 null 여부를 검사하는 이유가 뭔가용?
중복되는 거라면 빼도 되는 거 아닐까 싶은데 혹시 따로 처리를 하신 이유가 있는지 궁금합니다~!
엔티티는 데이터 저장 객체로서 데이터베이스와의 매핑만 책임져야 한다고 생각해서
만약 검증과 유효성 검사를 따로 진행하고 싶다면 엔티티 자체가 아닌 DTO나 서비스에서 하는게 맞지 않나 싶기도 해용
어떻게 생각하시나요?!
public DiaryEntity(String title, String content, String category) { | ||
if (title == null || content == null) { | ||
throw new IllegalArgumentException("Title과 Content는 반드시 필요합니다."); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이것도 위의 리뷰와 같이 null 처리를 하신 이유가 궁금합니다!
//회원가입 API | ||
|
||
@PostMapping("/signup") | ||
public ResponseEntity<UserEntity> registerUser(@RequestBody UserSignupRequest signupRequest){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UserEntity 를 직접 반환하는 방법 말고 다른 방법은 없을까요?
제가 알기로는 Entity의 경우 민감한 정보가 포함되어 있으면 그대로 노출될 수 있기 때문에 직접 반환하는 건 위험하다고 알고 있어서요!
또한 엔티티는 데이터베이스와 매핑되는 객체로서, 비즈니스 로직이나 데이터 저장, 조회만을 담당해야 한다고 생각해서 별도로 DTO를 생성해서 하는게 더 좋지 않을까 싶습니당
틀렸으면 말해주삼 킥킥 ><
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
밑에 보니까 UserResponse가 잇는데 이거 사용해도 되지 않을까용
@@ -0,0 +1,40 @@ | |||
package org.sopt.diary.user.api; | |||
|
|||
public class UserResponse { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이거 record로 하는게 더 편하지 않나용
@GeneratedValue(strategy = GenerationType.IDENTITY) | ||
private Long id; | ||
|
||
@Column(name = "username", nullable = false, unique = true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
히히 username 아니고 nickname이 unique=true 아닌가용
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
앗 이거 올리면 안돼용 ㅎㅎ .gitignore에 추가하기~!!
[3주차 과제] 회원가입 및 로그인 기능 구현
1. 회원가입
1.1 구현 방식
/users/signup
경로에 POST 요청을 통해 동작UserController
클래스의registerUser
메서드에서 회원가입 요청을 처리UserSignupRequest
DTO 객체로 매핑되도록 했다.UserService
에서 비즈니스 로직을 처리하고, 최종적으로UserRepository
에서 사용자 데이터를 DB에 저장한다.1.2 예외 처리
checkDuplicateNickname
메서드에서 중복성을 검사하도록 했음!1.3 특징
@Transactional
을 사용하여 사용자를 등록하는 과정에서 데이터 일관성을 보장2. 로그인
2.1 구현 방식
/users/login
경로에서 POST 요청을 통해 동작UserController
클래스의loginUser
메서드에서 로그인 요청을 처리UserLoginRequest
DTO 객체로 본문 데이터를 매핑합니다.UserService
에서 사용자 자격을 검증하는 로직이 수행됩니다.UserRepository
에서 사용자 데이터를 DB에 저장합니다.2.2 예외 처리
UserRepository
에서username
을 기준으로 사용자를 조회한 후 예외를 처리합니다.