[1주차 미션] 구현 완료했습니다. 리뷰 부탁드립니다. #82

mywnajsldkf · 2022-10-02T15:53:25Z

새롭게 알게 된 것

Builder 패턴
객체를 생성하기 위해 생성자 패턴, 정적 메서드 패턴, 수정자 패턴, 빌더 패턴등이 있다.
빌더 패턴을 권장하는 이유는 무엇일까?
빌더 패턴의 형태는 다음과 같다.

User user = User.builder()
                      .name("jeongin")
                      .id("wnajsldkf")
                      .password("1234").build();

이런 빌더 패턴의 장점은

필요한 데이터만 설정할 수 있다.
-> 정적 메서드를 이용하면 파라미터에 맞는 정적 메서드를 만들어야 한다.
유연성을 확보할 수 있다.
-> 새롭게 변수가 추가되어도, 기존 코드는 영향을 받지 않는다.
가독성을 높일 수 있다.
-> 어떤 변수가 무엇을 의미하는지 한눈에 알 수 있다.
변경 가능성을 최소화한다.
-> Setter를 사용해서 값을 넣지 않아도 된다.
출처: https://mangkyu.tistory.com/163

고민한 부분

DTO 사용
- DTO 변환은 어느 시점에 해야할까?
- DTO <-> Entity 변환에서 라이브러리 사용이 과연 도움되는가?(직접 해본 결과 코드를 작성하는 것이 더 편하기도 했음, 다만 어떤 곳에 변환 코드를 두어야할지 고민되었다.)
- 정보를 교환하는 상황 당 하나의 DTO로 생각하면 되는 것인가?
  => 정답이 없는 문제이고, 상황에 맞게 쓴다. 다만 DTO 사용 취지를 생각해봤을 때 Entity에서 사용하는 것은 지양한다.
  +) 고민에 도움이 된 글
  https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/
  https://www.inflearn.com/questions/24222
  그리고 이전 미션에서 코멘트들
생성자 주입(구현체를 생성할 때)
- 자바에서 제공하는 interface를 사용할 때, 생성자를 주입하고 싶은 경우 이것에 대한 구현체를 만들어서 하는게 맞는 것인가?
- Java의 applicationEventPublisher를 사용을 시도할 때 고민되었음
Spring Bean과 Java의 Static의 용도는 비슷한가?
- Static을 붙이면 메모리에 올라가서 생성하지 않고도 사용가능하고, Bean을 붙이면 실행되는 점에서 용도가 비슷하지 않을까 생각해봤음
- 이 글을 공유 받음 https://www.facebook.com/devbeginner/posts/1011209305658104/
개인적인 고민
- 나의 개발 속도가 너무 느리다. 요구사항을 이해하고 요구하는 것을(비약하지 말고!) 기간내에 완성하는 연습을 해야한다.

다음에 해보고 싶은 것

Listener 사용
- JPA Auditing 기능을 직접 구현해보려고 Listener를 사용하려고 했다. 왜 Listener를 사용하는지 상황을 제대로 이해하고 성공하고 싶다.

- 새로운 질문 작성 - 등록된 질문 조회

- mockito, mapstruct, lombok 사용을 위한 라이브러리 추가 - 불필요한 파일 삭제 - 경로 수정 - 불필요한 코드 삭제

- 질문 조회 - 질문 상세보기 - home 화면 이동

- DTOtoEntity - EntitytoDTO

- 사용자 정보 수정 페이지 불러오기 API - 사용자 정보 수정하기 API - 정보 수정 DTO 추가 - 정보 수정 서비스 - 정보 수정 레파지토리 추가

- 사용자 등록 - 사용자 정보 수정 - 특정 사용자 불러오기 - 모든 사용자 불러오기

- 질문 작성 - 특정 질문 불러오기 - 모든 질문 불러오기

saint6839 · 2022-10-04T11:34:36Z

src/main/java/codesquad/dto/question/QuestionRequestDto.java

+
+import lombok.*;
+
+@NoArgsConstructor


기본 생성자를 생성해주신 이유가 있을까요?

saint6839 · 2022-10-04T11:41:08Z

src/main/java/codesquad/AppConfig.java

 import codesquad.repository.UserRepository;
+import codesquad.service.QuestionService;
+import codesquad.service.QuestionServiceImpl;
 import codesquad.service.UserService;
 import codesquad.service.UserServiceImpl;
 import org.springframework.context.annotation.Bean;
 import org.springframework.context.annotation.Configuration;

 @Configuration
 public class AppConfig {


컨트롤러는 @controller 어노테이션을 이용해 빈을 등록하고 계시는데, Service와 Repository는 Config 파일에서 빈을 따로 등록해주고 계시는 이유가 궁금합니다!

우선 의존성을 주입하여 코드/객체 간의 결합도를 낮추기 위해 Service와 Repository는 자바 코드로 직접 스프링 빈을 등록하였습니다. 이는 개발을 진행하다 Repository를 변경해야하는 상황일 때, Config에 등록된 Repository Bean만 수정하면 되기 때문입니다.

그럼 Controller의 역할을 생각해보겠습니다.
컨트롤러는 View와 Service를 이어주는 역할만 하고 비즈니스 로직을 가지고 있지 않습니다. 따라서 Repository가 변경되거나 비즈니스 로직이 변경되어도 Controller는 변경되지 않으므로 Config에서 등록하지 않았습니다.

ref: https://inf.run/SZEa -> 말 다듬는데 도움 받았습니다:)

의존성 주입은 스프링이 알아서 해주는 부분입니다 ~
스프링 부트의 DI 방식에 대해 알아보면 좋을 것 같아요

제어의 역전(IoC)가 무엇인지도 한 번 알아보시면 좋을 것 같습니다!

saint6839 · 2022-10-05T01:38:18Z

src/test/java/QuestionServiceImplTest.java

+public class QuestionServiceImplTest {
+
+    @Mock
+    private QuestionRepository questionRepository = new ArrayQuestionRepository();


Mockito와 Mock이 무엇을 의미하는지 공부해보시면 좋을 것 같습니다

saint6839 · 2022-10-05T01:38:41Z

src/test/java/QuestionServiceImplTest.java

+
+        // when
+        questionService.postQuestion(questionEntity);
+        List<QuestionEntity> questionEntityList = questionService.findQuestions();


Mock에 대해 알아보시고 Stubbing에 대해서 공부해보시면 좋을 것 같습니다!

@saint6839 피드백 감사합니다~ 확인하여 수정하였습니다!!

saint6839 · 2022-10-05T01:39:24Z

src/test/java/QuestionServiceImplTest.java

+    @InjectMocks
+    private QuestionService questionService = new QuestionServiceImpl(questionRepository);
+
+    void setUp() {


setUp()을 매번 호출해주는것도 결국 중복이라고 생각합니다! JUnit5 사용중이시라면 @beforeeach JUnit4라면 @before를 사용해보시면 좋을 것 같습니다

saint6839 · 2022-10-05T02:28:50Z

src/main/java/codesquad/repository/UserRepository.java

@@ -1,12 +1,15 @@
 package codesquad.repository;

+import codesquad.dto.user.UserUpdateRequestDto;
 import codesquad.entity.UserEntity;

 import java.util.List;

 public interface UserRepository {
    void register(UserEntity userEntity);


update()는 dto를 넘겨주고 있는데, register()는 엔티티를 넘겨주는 이유가 궁금합니다!

dto <-> entity 사이의 맵핑을 어디서 해야할지 고민을 했는데요.
DTO는 컨트롤러 레이어에 종속되어야 한다고 생각해 맵핑에 관련된 것은 모두 컨트롤러에서 두려고 하였습니다.

update()에 대한 부분은 피드백을 보고 다시 보니, 새로운 userEntity를 생성하는 register와 다르게 기존에 있는 userEntity를 수정하는 것이다보니 값을 update하는 방향에 집중했습니다. 그러다보니 DTO -> Entity도 새롭게 객체를 만든다는 생각에 거치지 않았네요.😅

다시보니 register() 처럼 controller에서 entity로 바꿔서 넘겨지고 entity에 있는 값들을 repository에서 꺼내어 업데이트하는 방식으로 수정하고 싶은데 @saint6839 님의 생각은 어떠세요?

+)
dto <-> entity는 어디에에 관한 부분은...
이전 리뷰에서도 질문드리기도 했고, 다양한 토론글 1, 토론글 2 등을 찾아보기도 했는데요~
스스로 내린 작업 방향성은 repository까지 들어가지 말 것, 프로젝트 내에 일관성을 유지할 것, (무엇보다) 같이 하는 사람이랑 맞출 것 입니다.🙂
이 부분에 대해 상엽님의 생각도 들어보고 싶네요~

dto <-> entity 사이의 맵핑을 어디서 해야할지 고민을 했는데요. DTO는 컨트롤러 레이어에 종속되어야 한다고 생각해 맵핑에 관련된 것은 모두 컨트롤러에서 두려고 하였습니다.

update()에 대한 부분은 피드백을 보고 다시 보니, 새로운 userEntity를 생성하는 register와 다르게 기존에 있는 userEntity를 수정하는 것이다보니 값을 update하는 방향에 집중했습니다. 그러다보니 DTO -> Entity도 새롭게 객체를 만든다는 생각에 거치지 않았네요.😅

다시보니 register() 처럼 controller에서 entity로 바꿔서 넘겨지고 entity에 있는 값들을 repository에서 꺼내어 업데이트하는 방식으로 수정하고 싶은데 @saint6839 님의 생각은 어떠세요?

+) dto <-> entity는 어디에에 관한 부분은... 이전 리뷰에서도 질문드리기도 했고, 다양한 토론글 1, 토론글 2 등을 찾아보기도 했는데요~ 스스로 내린 작업 방향성은 repository까지 들어가지 말 것, 프로젝트 내에 일관성을 유지할 것, (무엇보다) 같이 하는 사람이랑 맞출 것 입니다.🙂 이 부분에 대해 상엽님의 생각도 들어보고 싶네요~

개인적으로는 Entity <-> Dto 변환 책임을 서비스 계층에 부여하는것을 선호하는 편입니다. 컨트롤러 계층의 메서드 네이밍은 비즈니스 용어를, 서비스 계층의 메서드 네이밍은 개발 용어를 사용한다는 영상을 본 적이 있습니다(아마도 김영한님).

그만큼 컨트롤러 계층은 개발적인 요소보다는 사용자로부터 들어온 요청을 처리하는데 책임이 집중되어야 하는 계층이라고 생각합니다. 이러한 이유 때문에 저는 서비스 계층에서 Entity와 Dto 변환을 다루는 것을 선호하는 편입니다.

정답은 없는 것 같지만 본인이 선호하는 방법이 있다면, 그 근거에 대해서 생각해보시면 좋을 것 같아요(단순히 대부분 사람들이 그렇다고 해서가 아닌..)

@saint6839
저는 service(application or usecase), domain 은 외부의 것으로부터 독립적이고 최대한 순수한 응답을 보내야 사용성이 좋아진다고 생각합니다.
따라서 service 레이어에서는 외부 요구사항에 해당하는 데이터 구조인 dto 변환을 지양하도록 개발하는 편입니다. 실제 서비스에서 개발하다보면 1controller - 1service 가 아니라 n개의 controller 케이스에서 서로 다른 목적으로 1service 를 호출하는 케이스도 있으니 각자가 필요한 데이터가 다를 경우, dto 가 공통으로 사용되어서 뚱뚱해지고 무엇이 어떤 케이스에 꼭 필요한 데이터인지 구분하기도 어려워집니다. 그리고 서로의 변경에 영향도 많이 받구요.
그렇다고 entity 를 순수하게 그대로 반환하게 되면 OSIV 고민에 빠지게 됩니다. 그래서 좀 복잡한 코드에서는 Service layer DTO 를 따로 정의해서 그것으로 변환하여 공통적으로 반환해주고, controller 에서는 service dto 를 받아서 필요한 부분들을 다시 controller layer dto 로 변환해서 사용하기도 합니다. 너무 클래스가 많아지고 오히려 복잡해진다는 경향이 있어서 이런 토이플젝에서는 추천하지 않지만 이런 부분도 있구나 하고 넘기셔도 좋을 것 같아서 공유드립니다 ~
이 케이스에서는 작은 규모이니 그냥 service layer 에서 dto 변환을 하는 것을 추천합니다 ~

@saint6839 @hyukjin-lee
의견 공유감사합니다 :)
두분의 피드백을 받아 수정하였습니다!

saint6839 · 2022-10-05T02:33:26Z

src/main/java/codesquad/service/QuestionServiceImpl.java

+
+    @Override
+    public void postQuestion(QuestionEntity questionEntity) {
+        questionRepository.post(questionEntity);


엔티티를 이용해 데이터를 주고 받으면 어떤 문제가 있을지 고민해보시면 좋을 것 같습니다!

Entity, Model, Dto, VO의 차이에 대해 알아보시면 좋을 것 같아요

엔티티를 이용해 데이터를 주고 받으면 어떤 문제가 있을지 고민해보시면 좋을 것 같습니다!

네! 한번 고민해보겠습니다~ 혹시 상엽님이 말씀하신 데이터를 주고 받는 부분은 view(controller)와 주고받는다는 말씀이실까요?

Entity, Model, Dto, VO의 차이에 대해 알아보시면 좋을 것 같아요

조언 감사합니다~

공부하면서 궁금한 점이 있습니다.

아직 VO를 사용하는 이유가 와닿지 않는데요~
DTO처럼 데이터를 전송하는 상황에만 쓴다는 것이 아닌,
VO의 제약사항(불변성, 동등성, 자가 유효성)이 있기에
객체 생성 시 VO 그 자체가 제약사항이 되거나 인스턴스가 정해져 있는 경우 미리 인스턴스를 생성하는 등
VO의 특징으로 얻을 수 있는 이점이 있기에 사용한다고 이해해도 될까요?

아래부터는 정리한 내용입니다.

Entity

DB의 테이블과 매핑되는 객체로, id를 통해 각각의 Entity를 구분합니다.

로직을 가질 수 있습니다.

public class User { private Long id; private String name; private String email; @Builder public User(String name, String email) { this.name = name; this.email = email; } public User update(String name, String email) { this.name = name; this.email = email; return this; } }

DTO

Data Transfer Object, 말 그대로 계층(Layer: Service, Controller, Repository)간 데이터 교환을 위해 사용하는 객체입니다.

로직을 갖지 않고, getter/setter 메소드만 갖습니다.

class UserDto { private int name; private int email; public UserDto(int name, int email){ this.name = name; this.email = email; } public int getName() { return name; } public int setName(int name) { this.name = name; } ... }

VO

Value Object의 약자로 값 그 자체입니다.
사용 시, 염두해야할 부분은 1. equals & hash code 메서드를 재정의해야 한다. 2. 수정자(setter)가 없는 불변 객체여야 한다. 입니다.
1번에 대해 좀 더 이야기하자면 동등성을 갖기 때문에 객체가 실제 다른 객체이더라도, 논리적으로 값이 같다면(나의 아이폰 13미니, 너의 휴대폰 13미니 서로 다르지만 같음) 같다고 말합니다.
2번은 setter가 없어서 값 변경 걱정이 없어 DB에서 값을 가져와 데이터를 VO에 담으면 항상 VO의 값을 원본으로 신뢰할 수 있습니다.

+) 잘 정리된 글도 첨부합니다.

https://tecoble.techcourse.co.kr/post/2020-06-11-value-object/

https://hudi.blog/value-object/

Model

Model은 비즈니스 로직에서 발생하는 값이라고 생각합니다.
DB에 값을 넣거나 가져오는 것이 아닌 중간에 연산이 이루어질 때 필드들을 모델에 담아 관리한다고 생각합니다.

엔티티를 이용해 데이터를 주고 받으면 어떤 문제가 있을지 고민해보시면 좋을 것 같습니다!

네! 한번 고민해보겠습니다~ 혹시 상엽님이 말씀하신 데이터를 주고 받는 부분은 view(controller)와 주고받는다는 말씀이실까요?

컨트롤러 뿐 아니라 레이어드 아키텍쳐에서 각 계층간에 데이터를 주고 받는 것을 의미합니다!

아직 1단계라서 이런 부분에 대한 코멘트는 좀 더 친절히 설명해주어도 좋을 것 같습니다.

@saint6839
DTO 없이 Entity만 존재한다면 DB와 매핑된 Entity가 변경되면 연결된 다른 클래스들이 영향을 받습니다.
DTO가 있으면 변경이 필요한 부분(특정 데이터들만 가져오거나, 특정 데이터들만 저장하는 등에서 통신하는 DTO에서 처리하고 마지막에 DB와 매핑하는 부분만 Entity에서 처리하도록 하여 클래스에 미치는 영향을 줄일 수 있을 것입니다.

정인님 저는 솔직하게 상엽님이 말씀하신 Entity, Model, DTO, VO 를 제대로 구분짓는게 어려워요,,,
그래서 제 나름대로 쉽게 생각한걸 말씀드려볼게요
Entity는 정말 DB에 저장하는 것을 의미하고 최대한 변하지 않아야해요. Entity 스펙이 변경되버리면 모든 코드에 영향을 끼치게 되잖아요? 그래서 최대한 변하지 않는 것이 좋아요

DTO는 영어 그대로 Data를 이동시키는데 필요한 Object로 각 layer에 필요한 데이터들을 이동하는데 사용해요

이때 왜 Entity를 사용하지 않고 DTO를 사용하느냐?
Entity의 스펙이 변경되어버리면(변경되지 않아야 좋음) 모든 코드가 다 변경되기 때문에 최대한 그러지 않으려고 사용하는 것 같아요,,

Model은 그냥 내가 비즈니스 로직 수행하고 반환하는 객체구나, VO는 그렇구나 하고 넘어가는 편이에요,,

당연히 고민하는 건 좋지만 너무 많은 고민을 하실까봐 남겨봅니다..!! 제가 말씀드린 것도 답이 아닐 수도 있어요~~

saint6839 · 2022-10-05T02:39:04Z

src/main/java/codesquad/controller/QuestionController.java

+@Controller
+public class QuestionController {
+    ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
+    QuestionService questionService = applicationContext.getBean("questionService", QuestionService.class);


applicationcontext로부터 직접 빈을 가져오셔서 사용하신 이유가 궁금합니다!

AppConfig에서 @componentscan 같은 Spring Bean을 자동으로 가져오기 위한 어노테이션을 사용하지 않았기에 직접 빈을 가져왔습니다!
(사실 질문 의도를 제대로 이해하지 못했습니다. 부연 설명 해주시면 감사하겠습니다!)

스프링부트에서 생성자 주입을 하는 방법에 대해 검색해보시면 좋을 것 같아요

applicationcontext로부터 직접 빈을 가져오셔서 사용하신 이유가 궁금합니다!

questionService는 다음과 같이 생성자를 통해 주입되었습니다.

AppConfig

@Bean public QuestionService questionService() { return new QuestionServiceImpl(questionRepository()); } @Bean public QuestionRepository questionRepository() { return new QuestionRepositoryImpl(); }

QuestionServiceImpl

public QuestionServiceImpl(QuestionRepository questionRepository) { this.questionRepository = questionRepository; }

생성자 주입을 한 경우, getBean()을 통해 객체를 얻어와서 사용해야 합니다.

saint6839 · 2022-10-05T02:40:57Z

src/main/java/codesquad/controller/UserController.java

+        return "user/update_form";
+    }
+
+    @PutMapping("/{userId}/update")


업데이트에는 보통 PUT과 PATCH가 사용됩니다. 이 둘의 차이는 무엇일까요?

PUT은 자원 전체를 교체하여, 자원의 모든 필드가 필요하고
PATCH는 자원의 부분만 교체하여, 자원의 일부 필드만 있어도 됩니다.

GOOD

PUT /userId/1 { "userId" : "mywnajsldkf", "age" : 24 } GET /userId/1 { "userId" : "mywnajsldkf", "age" : 24 }

BAD

PUT /userId/1 { "userId" : "mywnajsldkf", } GET /userId/1 { "userId" : "mywnajsldkf", "age" : null }

GOOD

PATCH /userId/1 { "userId" : "mywnajsldkf", } GET /userId/1 { "userId" : "mywnajsldkf", "age" : 24 }

hyukjin-lee · 2022-10-07T05:32:30Z

src/main/java/codesquad/mapper/QuestionMapper.java

+
+        QuestionResponseDto.QuestionResponseDtoBuilder questionResponseDto = QuestionResponseDto.builder();
+
+        questionResponseDto.writer(questionEntity.getWriter());


변수는 private 으로 선언하고 setter 를 사용해서 접근하는게 자바의 일반적인 원칙입니다 ~

@hyukjin-lee 넵!!! 기억하겠습니다. 이번에는 변경 가능성을 열어두는 setter 사용을 지양하고, 필요한 데이터만 설정하고 싶어 Builder 패턴을 사용해보았습니다~

hyukjin-lee · 2022-10-07T05:32:57Z

src/main/java/codesquad/repository/ArrayQuestionRepository.java

+import java.util.ArrayList;
+import java.util.List;
+
+public class ArrayQuestionRepository implements QuestionRepository {


Array 라는 자료구조를 노출하신 이유가 있을까요~? QuestionRepositoryImpl 이라는 명칭이면 적당하지 않을까 싶습니다~

@hyukjin-lee
구현체는 변경될 수 있으니 구분을 위해 구체적인 자료구조를 노출하였습니다.
피드백 받고 찾아보니 일반적으로 구현 클래스는 일반적으로 상속하고 있는 인터페이스명 + Impl 작성한다고 하네요!
수정하겠습니다!

일반적으로 Impl 을 사용하지만, 현재 DB를 사용하지 않고 List를 사용해서 class 이름을 이렇게 하지 않았나 예상됩니다
만약 List를 사용한다고 명시하고 싶으시면 제 생각엔 메모리에 저장하는 것과 같아서 QuestionMemoryRepositoryImpl 도 괜찮을 것 같아요~

hyukjin-lee · 2022-10-07T05:33:38Z

src/main/java/codesquad/entity/QuestionEntity.java

+@Builder
+@NoArgsConstructor
+@AllArgsConstructor
+public class QuestionEntity extends BaseTimeEntity {


Entity 라는 postfix 를 붙이지 않아도 될 것 같습니다 ~

@hyukjin-lee class명 말씀하실까요??

넵넵 QuestionEntity -> Question 을 말씀하시는 것 같아요~

hyukjin-lee

고생하셨습니다 ~ 답변이 어느정도 되는것 같으면 머지시킬게요 ~
의존주입하는 부분만 좀 고치면 될 것 같네요

- `상속하고 있는 인터페이스 명` + Impl

- UserUpdateDTOtoEntity 메서드 추가

mywnajsldkf added 28 commits September 16, 2022 10:54

refactor: TDA 법칙 적용

d964fa5

chores: 불필요한 코드 삭제

c2a8bb1

feat: 질문하기 화면 불러오기

90273dc

feat: QuestionEntity 생성

e2652c9

feat: 질문 등록 시간 관리를 위한 BaseTimeEntity 생성

5054a4e

feat: Question 인터페이스와 구현 객체 생성

8218760

feat: 질문 작성 시, Dto -> Entity을 위한 Dto 생성

97a4aa2

feat: Question 비즈니스 로직 인터페이스, 구현체 생성

123f64e

- 새로운 질문 작성 - 등록된 질문 조회

feat: 질문 서비스 생성자 주입

4515430

chores

63c99ce

- mockito, mapstruct, lombok 사용을 위한 라이브러리 추가 - 불필요한 파일 삭제 - 경로 수정 - 불필요한 코드 삭제

feat: Dto -> entity를 위한 Mapper 생성

9e2d8ae

test: 질문 등록 테스트 추가

382a57d

feat: 질문 등록 기능 구현

92f9a9b

chores: 경로 수정

d913d6e

feat: Question API 작성

52bffd1

- 질문 조회 - 질문 상세보기 - home 화면 이동

feat: QuestionMapper 작성

c8b0b11

- DTOtoEntity - EntitytoDTO

chores: 불필요한 파일, 어노테이션 삭제

eb1d90c

feat: qna 화면 추가

e06bf9c

view: 질문 상세보기 연결

f2ad0aa

feat: QuestionEntity 반환

ed79049

feat: index가 1부터 시작하도록 함수 작성

30f2e6a

feat: QuestionResponseDto 작성

9f2fa60

view: 회원 정보 수정 화면 추가, 수정하기와 상세보기 경로 수정

a1ed8bd

feat: 사용자 정보 수정

35a173d

- 사용자 정보 수정 페이지 불러오기 API - 사용자 정보 수정하기 API - 정보 수정 DTO 추가 - 정보 수정 서비스 - 정보 수정 레파지토리 추가

chores: 메서드명 수정

69b83ea

chores: @builder 어노테이션 추가

f8e118b

test: UserServiceImpl 테스트 코드 작성

34f467f

- 사용자 등록 - 사용자 정보 수정 - 특정 사용자 불러오기 - 모든 사용자 불러오기

test: QuestionService 테스트 코드 작성

0f27f1a

- 질문 작성 - 특정 질문 불러오기 - 모든 질문 불러오기

saint6839 reviewed Oct 4, 2022

View reviewed changes

saint6839 reviewed Oct 5, 2022

View reviewed changes

hyukjin-lee reviewed Oct 7, 2022

View reviewed changes

hyukjin-lee approved these changes Oct 7, 2022

View reviewed changes

mywnajsldkf added 4 commits October 14, 2022 13:00

refactor: Impl 클래스 명 변경

201d490

- `상속하고 있는 인터페이스 명` + Impl

refactor: UserUpdate DTO -> Entity Controller에서 하도록 수정

d8268ec

- UserUpdateDTOtoEntity 메서드 추가

chores: 불필요한 코드 삭제

06ad635

refactor: mockito를 사용하여 테스트하도록 수정

3df9a5e


		QuestionResponseDto.QuestionResponseDtoBuilder questionResponseDto = QuestionResponseDto.builder();

		questionResponseDto.writer(questionEntity.getWriter());

[1주차 미션] 구현 완료했습니다. 리뷰 부탁드립니다. #82

Are you sure you want to change the base?

[1주차 미션] 구현 완료했습니다. 리뷰 부탁드립니다. #82

Conversation

mywnajsldkf commented Oct 2, 2022

새롭게 알게 된 것

고민한 부분

다음에 해보고 싶은 것

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mywnajsldkf Oct 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyukjin-lee Oct 8, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Entity

DTO

VO

Model

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hyukjin-lee left a comment

Choose a reason for hiding this comment

mywnajsldkf Oct 5, 2022 •

edited

Loading

hyukjin-lee Oct 8, 2022 •

edited

Loading