Conversation
bs8841
added
매운맛🔥
| public class DiscodeitApplication { | ||
|
|
||
| static User setupUser(UserService userService) { | ||
| UserCreateRequest request = new UserCreateRequest("woody", "[email protected]", "woody1234"); |
There was a problem hiding this comment.
이 프로젝트에서 lombok을 사용하고 있는데, 기왕 롬복을 사용할거라면 인스턴스를 생성할때도 Builder 패턴을 사용하길 권장드려요.
이유는 new 생성자로 생성하는건 파라미터의 순서와 갯수를 매번 고려해야하고 읽는 사람이 가독성이 떨어지는 단점이 있어요.
반면에 Builder 패턴은 어떤 변수에 어떤 값이 들어갈지 바로 보이기 때문에 가독성이나 순서와 갯수를 고려하지 않아도 돼죠.
현대화된 언어들에서는Named Parameter라는 개념으로 파라미터를 호출할때 지정하는 방법이 있는데, 자바에서는 아직 그게 없네요 ㅎㅎ 그래서 builder 패턴을 사용하는거에요.
참고
빌터패턴 : https://gwonbookcase.tistory.com/100?category=777301
Dart의 Named parameter : https://leftday.tistory.com/120
|
|
||
| static User setupUser(UserService userService) { | ||
| UserCreateRequest request = new UserCreateRequest("woody", "[email protected]", "woody1234"); | ||
| User user = userService.create(request, Optional.empty()); |
There was a problem hiding this comment.
파라미터로 Optional을 받는건 조금 어색한거 같아요. 일단 Optional을 파라미터로 받는건 안티패턴으로 알고 있어요. Optional은 반환값을 관리위해서 사용된 개념이어서요.
참고 : https://yeonyeon.tistory.com/224
질문에도 있던 사항인거 같아 같이 답을 드리면, 나중에 Rest API 형태로 구현할거라 생각이 되는데요. 그때 보통 Controller에서 Multipart 형태로 데이터를 받을거에요. 파일 자체가 크니까 Controller에서 local에 특정 경로(여러 저장 요청을 동시에 받을 수 있으므로 경로 timestamp로 경로 구분해서) 에 저장해두고 그 경로만 UserCreateRequestDTO에 같이 넣는게 좋을거 같아요. 파일을 안 받은 경우에는 그 경로는 null로 할지 아니면 boolean으로 파일을 받았는지 아닌지 관리할지는 정하시면 될거 같아요.
그리고 Controller에서 finally 혹은 try-resources로 반드시 local에 저장해둔 파일 있으면 삭제까지 하구요.
그런데 요구사항에서 User랑 Message에서 BinaryContent를 의존하는걸로 봐서는 코드 내에서 파일 바이너리 값은 전체를 계속 다룰 생각인가 보내요. 그 바이너리 값도 UserCreateRequestDTO 안에 있는게 더 좋을거 같아요. 그게 더 직관적일거 같아요
|
|
||
| static void messageCreateTest(MessageService messageService, Channel channel, User author) { | ||
| MessageCreateRequest request = new MessageCreateRequest(channel.getId(), author.getId(), "안녕하세요."); | ||
| Message message = messageService.create(request, new ArrayList<>()); |
There was a problem hiding this comment.
여기에서도 ArrayList 파라미터 더 받지 말고 파일은 미리 처리하고 필요한 변수들은 최대한 MessageCreateRequest 안에서 가지고 있도록 작성해주세요.
변수를 여러개 받아야한다는걸 매번 고민하는 것 보다 MessageCreateRequest에 필요한 변수가 다 있는 형태가 더 직관적이라고 생각해요.
|
고생하셨습니다. 백선님. 전체적으로 완벽한 코드라 생각합니다 ㅎㅎ 위의 것들만 고쳐주시면 바로 머지해도 될것 같습니다. |
| List<UUID> joinedChannelIds = readStatusRepository.findAllByUserId(userId) | ||
| .stream().map(ReadStatus::getChannelId).toList(); | ||
|
|
||
| return channelRepository.findAll().stream() |
There was a problem hiding this comment.
백선님도 잘 작성하신줄 알았는데 개선해야할 부분이 있네요.
channelRepository.findAll()로 하면 성능상 문제가 될거에요.
channelRepository.findByUserIds(List<UUID> userIds) 이렇게 찾는게 있었으면 좋겠어요.
요구사항
기본
Spring 프로젝트 초기화
[x] Spring Initializr를 통해 zip 파일을 다운로드하세요.
[x] 빌드 시스템은 Gradle - Groovy를 사용합니다.
[x] 언어는 Java 17를 사용합니다.
[x] Spring Boot의 버전은 3.4.0입니다.
[x] GroupId는 com.sprint.mission입니다.
[x] ArtifactId와 Name은 discodeit입니다.
[x] packaging 형식은 Jar입니다
[x] Dependency를 추가합니다.
[x] Lombok
[x] Spring Web
[x] zip 파일을 압축해제하고 원래 진행 중이던 프로젝트에 붙여넣기하세요. 일부 파일은 덮어쓰기할 수 있습니다.
[x] application.properties 파일을 yaml 형식으로 변경하세요.
[x] DiscodeitApplication의 main 메서드를 실행하고 로그를 확인해보세요.
Bean 선언 및 테스트
[x] FileRepository 구현체를 Repository 인터페이스의 Bean으로 등록하세요.
[x] BasicService 구현체를 Service 인터페이스의 Bean으로 등록하세요.
[x] JavaApplication에서 테스트했던 코드를 DiscodeitApplication에서 테스트해보세요.
[x] JavaApplication 의 main 메소드를 제외한 모든 메소드를 DiscodeitApplication클래스로 복사하세요.
[x] JavaApplication의 main 메소드에서 Service를 초기화하는 코드를 Spring Context를 활용하여 대체하세요.
[x] JavaApplication의 main 메소드의 셋업, 테스트 부분의 코드를 DiscodeitApplication클래스로 복사하세요.
Spring 핵심 개념 이해하기
[x] JavaApplication과 DiscodeitApplication에서 Service를 초기화하는 방식의 차이에 대해 다음의 키워드를 중심으로 정리해보세요.
IoC Container
Dependency Injection
Bean
new키워드 등으로 명시적으로 생성하여 주입함 (수동 주입)@Autowired또는 생성자 기반으로 의존성을 자동 주입함 (자동 주입)@Component,@Service,@Repository,@Bean등을 통해 등록된 객체들이 Spring IoC Container에 의해 Bean으로 관리됨Lombok 적용
[x] 도메인 모델의 getter 메소드를 @Getter로 대체해보세요.
[x] Basic*Service의 생성자를 @requiredargsconstructor로 대체해보세요.
비즈니스 로직 고도화
[x] 다음의 기능 요구 사항을 구현하세요.
시간 타입 변경하기
[x] 시간을 다루는 필드의 타입은 Instant로 통일합니다.
기존에 사용하던 Long보다 가독성이 뛰어나며, 시간대(Time Zone) 변환과 정밀한 시간 연산이 가능해 확장성이 높습니다.
[x] 공통: 앞서 정의한 도메인 모델과 동일하게 공통 필드(id, createdAt, updatedAt)를 포함합니다.
[x] ReadStatus
[x] UserStatus
[x] 마지막 접속 시간을 기준으로 현재 로그인한 유저로 판단할 수 있는 메소드를 정의하세요.
[x] BinaryContent
[x] 수정 불가능한 도메인 모델로 간주합니다. 따라서 updatedAt 필드는 정의하지 않습니다.
[x] User, Message 도메인 모델과의 의존 관계 방향성을 잘 고려하여 id 참조 필드를 추가하세요.
[x] 각 도메인 모델 별 레포지토리 인터페이스를 선언하세요.
UserService 고도화
고도화
create
[x] 선택적으로 프로필 이미지를 같이 등록할 수 있습니다.
[x] DTO를 활용해 파라미터를 그룹화합니다.
유저를 등록하기 위해 필요한 파라미터, 프로필 이미지를 등록하기 위해 필요한 파라미터 등
[x] username과 email은 다른 유저와 같으면 안됩니다.
[x] UserStatus를 같이 생성합니다.
find, findAll
DTO를 활용하여:
[x] 사용자의 온라인 상태 정보를 같이 포함하세요.
[x] 패스워드 정보는 제외하세요.
update
[x] 선택적으로 프로필 이미지를 대체할 수 있습니다.
[x] DTO를 활용해 파라미터를 그룹화합니다.
수정 대상 객체의 id 파라미터, 수정할 값 파라미터
delete
[x] 관련된 도메인도 같이 삭제합니다.
BinaryContent(프로필), UserStatus
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
login
[x] username, password과 일치하는 유저가 있는지 확인합니다.
[x] 일치하는 유저가 있는 경우: 유저 정보 반환
[x] 일치하는 유저가 없는 경우: 예외 발생
[x] DTO를 활용해 파라미터를 그룹화합니다.
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
ChannelService 고도화
고도화
create
PRIVATE 채널과 PUBLIC 채널을 생성하는 메소드를 분리합니다.
[x] 분리된 각각의 메소드를 DTO를 활용해 파라미터를 그룹화합니다.
PRIVATE 채널을 생성할 때:
[x] 채널에 참여하는 User의 정보를 받아 User 별 ReadStatus 정보를 생성합니다.
[x] name과 description 속성은 생략합니다.
PUBLIC 채널을 생성할 때에는 기존 로직을 유지합니다.
find
DTO를 활용하여:
[x] 해당 채널의 가장 최근 메시지의 시간 정보를 포함합니다.
[x] PRIVATE 채널인 경우 참여한 User의 id 정보를 포함합니다.
findAll
DTO를 활용하여:
[x] 해당 채널의 가장 최근 메시지의 시간 정보를 포함합니다.
[x] PRIVATE 채널인 경우 참여한 User의 id 정보를 포함합니다.
[x] 특정 User가 볼 수 있는 Channel 목록을 조회하도록 조회 조건을 추가하고, 메소드 명을 변경합니다. findAllByUserId
[x] PUBLIC 채널 목록은 전체 조회합니다.
[x] PRIVATE 채널은 조회한 User가 참여한 채널만 조회합니다.
update
[x] DTO를 활용해 파라미터를 그룹화합니다.
수정 대상 객체의 id 파라미터, 수정할 값 파라미터
[x] PRIVATE 채널은 수정할 수 없습니다.
delete
[x] 관련된 도메인도 같이 삭제합니다.
Message, ReadStatus
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
MessageService 고도화
고도화
create
[x] 선택적으로 여러 개의 첨부파일을 같이 등록할 수 있습니다.
[x] DTO를 활용해 파라미터를 그룹화합니다.
findAll
[x] 특정 Channel의 Message 목록을 조회하도록 조회 조건을 추가하고, 메소드 명을 변경합니다. findallByChannelId
update
[x] DTO를 활용해 파라미터를 그룹화합니다.
수정 대상 객체의 id 파라미터, 수정할 값 파라미터
delete
[x] 관련된 도메인도 같이 삭제합니다.
첨부파일(BinaryContent)
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
ReadStatusService 구현
create
[x] DTO를 활용해 파라미터를 그룹화합니다.
[x] 관련된 Channel이나 User가 존재하지 않으면 예외를 발생시킵니다.
[x] 같은 Channel과 User와 관련된 객체가 이미 존재하면 예외를 발생시킵니다.
find
[x] id로 조회합니다.
findAllByUserId
[x] userId를 조건으로 조회합니다.
update
[x] DTO를 활용해 파라미터를 그룹화합니다.
수정 대상 객체의 id 파라미터, 수정할 값 파라미터
delete
[x] id로 삭제합니다.
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
UserStatusService 고도화
create
[x] DTO를 활용해 파라미터를 그룹화합니다.
[x] 관련된 User가 존재하지 않으면 예외를 발생시킵니다.
[x] 같은 User와 관련된 객체가 이미 존재하면 예외를 발생시킵니다.
find
[x] id로 조회합니다.
findAll
[x] 모든 객체를 조회합니다.
update
[x] DTO를 활용해 파라미터를 그룹화합니다.
수정 대상 객체의 id 파라미터, 수정할 값 파라미터
updateByUserId
[x] userId 로 특정 User의 객체를 업데이트합니다.
delete
[x] id로 삭제합니다.
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
BinaryContentService 구현
create
[x] DTO를 활용해 파라미터를 그룹화합니다.
find
[x] id로 조회합니다.
findAllByIdIn
[x] id 목록으로 조회합니다.
delete
[x] id로 삭제합니다.
의존성
같은 레이어 간 의존성 주입은 순환 참조 방지를 위해 지양합니다. 다른 Service 대신 필요한 Repository 의존성을 주입해보세요.
새로운 도메인 Repository 구현체 구현
[x] 지금까지 인터페이스로 설계한 각각의 Repository를 JCF, File로 각각 구현하세요.
심화
Bean 다루기
[x] Repository 구현체 중에 어떤 구현체를 Bean으로 등록할지 Java 코드의 변경 없이 application.yaml 설정 값을 통해 제어해보세요.
[x] discodeit.repository.type 설정값에 따라 Repository 구현체가 정해집니다.
[x] 값이 jcf 이거나 없으면 JCFRepository 구현체가 Bean으로 등록되어야 합니다.
[x] 값이 file 이면 FileRepository 구현체가 Bean으로 등록되어야 합니다.
[x] File*Repository 구현체의 파일을 저장할 디렉토리 경로를 application.yaml 설정 값을 통해 제어해보세요.
주요 변경사항
스크린샷
멘토에게