Week3 Assignment - Eul97 #17
Conversation
|
|
||
| e.printStackTrace(); | ||
|
|
||
| return ResponseEntity.ok(resDto); |
There was a problem hiding this comment.
예외에 대한 응답처리이니 header에 200보다는 404와 같은 httpStatus 값이 들어갈 수 있도록 badRequest()? 와 같은 매서드를 사용해도 나쁘지 않아보이네영
There was a problem hiding this comment.
실패한 경우 code에 -1을 넣어서 response 하라고 하셔성 이렇게 했습니당
|
|
||
| private String description; | ||
|
|
||
| @CreationTimestamp |
There was a problem hiding this comment.
오 아직 hibernate는 안배웠는데 요 어노테이션이 달려있네여
이거는 db 계층에서 인서트 시점에 값을 넣어주는건가여 아니면 객체 생성시점에 넣어주는건가요?
There was a problem hiding this comment.
service에서 객체 생성하고 넣어주었습니당
| } | ||
|
|
||
| private void validate(String name) { | ||
| if (name == null) |
There was a problem hiding this comment.
null 체크도 꼼꼼하게 👍 👍
관련해서 @NotNull 어노테이션을 사용하면 좀 더 깔끔하고 DTO에서 확실하게 잡아줄수있을것 같습니다 ~~
이거는 추가적으로 해봤으면 좋겠다 하는 생각
There was a problem hiding this comment.
짧은 if 문이라도 가독성을 위해서 중괄호는 포함하는것이 좋아보여여
나중에 추가해서 코드를 넣을때 별도로 작성하지 않아도 되고
clean code 책 추천~
| private Integer count; | ||
| } | ||
|
|
||
| public void convert(com.landvibe.week3.entity.Category categoryEntity) { |
There was a problem hiding this comment.
👍 👍
여기 위치에 DTO<->Entity를 변환하는 코드를 작성하는 것도 좋지만 나중에 복잡한 비즈니스 요청을 처리하는 Dto의 경우 관련된 entity가 늘어나면 클래스가 무거질수도 있어서
Mapper 클래스를 만드는것도 좋아보입니다요
MapStruct는 Entity <-> Dto 를 변환하는 코드를 생성해주는 라이브러리인데 나중에 한번 찾아보고 사용해봐도 좋을듯 합니당
| public class GetCategoryResDto { | ||
|
|
||
| private Integer size; | ||
| private List<Category> categories; |
There was a problem hiding this comment.
하나의 Transaction 내에서 Entity가 변화에 대해 열려있다면 수정되는 위험성이 있기때문에
Service Layer에서 Controller로 던져지는 클래스 (Dto)의 경우에는 Entity를 직접 사용하기 보다는
Dto로 변환해서 사용하는것이 조금더 안전할것 같습니다~
There was a problem hiding this comment.
이게 정확히 무슨 뜻인지 이해가 잘안됩니다,,
List categories이거를 말하는건가여?
There was a problem hiding this comment.
오 하나의 Entity도 DTO 클래스를 만들어서 전달되면 더 좋겠다고 한건데
List -> List 이런식으로 실제 entity가 전달되지 않도록 하는게 좀 더 안전하게
코드를 쓸수있다는 말이었슴다~
요약
Spring MVC를 활용해 예약 서비스를 만들어 보았습니다.
수업에서 말씀해주셨던 의존성 주입의 방법과 왜 Spring에서는 생성자 주입을 권장하는지에 대해서도 공부해 보았습니다.
의존성 주입에는 3가지 방법이 있습니다.
필드 주입은 멤버 객체에 Autowired 어노테이션을 붙여 주입받는 방법으로 타입이 같은 객체를 빈팩토리에서 검색해 사용합니다. 같은 타입의 객체가 여러개인 경우 Primary나 Qualifier와 같이 어노테이션으로 명시되어 있는 더 상세한 객체를 사용하게 됩니다.
수정자 주입은 setter 메소드 위에 Autowired 어노테이션을 붙여 주입받는 방법으로 메소드의 파라미터에 해당하는 객체를 빈팩토리에서 가져와 사용하게 됩니다.
생성자 주입은 말 그대로 생성자를 통해 멤버 객체를 주입받는 방법입니다. 생성자가 호출되면서 의존 객체가 빈팩토리를 통해 가져와 사용하게 됩니다. 따라서 해당 객체가 만들어지는 시점에 의존관계에 있는 모든 객체들을 빈팩토리에서 가져와야 합니다.
Spring에서는 생성자 주입을 권장하고 있습니다. 그 이유로는 생성자 주입은 객체가 생성되고 나면 의존관계에 있는 멤버 객체들을 변하지 않게(final) 할 수 있습니다. Field와 Setter에서는 자신 객체가 생성되는 시점에 의존관계에 있는 멤버 객체들은 초기에 null이었다가 이후 빈팩토리에서 객체를 찾아 와 주입해주는 방식입니다. 따라서 final 키워드가 사용 불가능해 이미 할당된 객체가 null이 되거나 새로운 instance가 할당되는것을 막을 수 없습니다. 그러나 생성자 주입의 경우 자신 객체가 생성될 때 멤버 객체의 주입이 이루어져서 final 키워드를 사용할 수 있습니다. 어플리케이션이 실행된 후에 의존 관계가 바뀌는 경우는 없으므로 final 키워드를 통해 변경의 가능성을 배제할 수 있게 됩니다.
클래스 A가 B를 멤버로 가지고, B 또한 A를 멤버 객체로 가지는 경우, 순환참조가 이루어지게 되는데 생성자 주입을 사용하면 컴파일 단계에서 이를 확인할 수 있습니다. 위 경우, 필드 주입과 수정자 주입은 객체가 이상없이 생성되고 서비스 또한 원활하게 구동이 될 수 있는 반면에 생성자 주입의 경우 A의 생성자가 호출되면 B의 생성자가 호출되고, 또 B의 생성자가 A의 생성자를 호출하고 이런 식으로 끝없이 서로를 참조하게 되어 에러를 발생시킵니다. 잘못된 코드가 서비스되는것을 미연에 방지할 수 있게 됩니다.
이 외에도 RequiredArgsConstructor 어노테이션과 활용해 코드가 간편해지고 NPE를 미연에 확인할 수 있고 테스트 코드를 작성하기 편하다는 장점 또한 있습니다.
편리함과 안정성 측면에서 생성자 주입이 가지는 장점이 명확하므로 스프링에서도 생성자 주입을 권장하는 것 같습니다.
어려웠던 점
기억 안나는 부분들이 많아서 구글링과 예전 코드들 뒤적이면서 했습니다.
코드리뷰 받고 싶은 점
모든 점에서 부탁드립니다.