[5기 - 김현우] Spring Boot Part3 Weekly Mission 제출합니다. by ASak1104 · Pull Request #972 · prgrms-be-devcourse/springboot-basic

ASak1104 · 2023-11-05T21:20:22Z

👩‍💻 요구 사항

바우처 관리 Command-line Application

(기본) 서비스 관리페이지 개발하기

Spring MVC를 적용해서 thymeleaf 템플릿을 설정해보세요.
커맨드로 지원했던 기능을 thymeleaf를 이용 해서 관리페이지를 만들고 다음 기능을 지원가능하게 해보세요
- 조회페이지
- 상세페이지
- 입력페이지
- 삭제기능

(기본) 바우처 서비스의 API 개발하기

Spring MVC를 적용해서 JSON과 XML을 지원하는 REST API를 개발해보세요
- 전체 조회기능
- 조건별 조회기능 (바우처 생성기간 및 특정 할인타입별)
- 바우처 추가기능
- 바우처 삭제기능
- 바우처 아이디로 조회 기능

🚀 애플리케이션 실행

프로젝트 초기 설정 및 애플리케이션 실행은 README.md 파일을 참고해주세요!

💡 고민했던 점

새로운 요구 사항으로 인해 모델과 인터페이스의 변경이 불가피했던 점
- 바우처 모델에 createAt 필드가 추가
- 바우처 레포지토리에 다양한 기능 추가
- 이러한 이유로 바우처 추상 클래스와 레포지토리 인터페이스를 사용하는 모든 클래스에 변경이 연쇄적으로 발생함
- 각 주차 별 과제에서 요구사항이 다이나믹하게 변경되다보니 특히 3주차 과제에서 변경 사항에 유연하게 대응하지 못 한 것 같습니다..
- 그 과정에서 정말 많은 것을 고민하고 경험할 수 있었습니다.
  - 인터페이스의 변경으로 그 구현체가 모두 해당 기능을 구현해야 한다.
  - 과연 웹에서만 사용할 기능을 위해 인테페이스를 변경할 필요가 있을까?
  - 이러한 변경이 초기 설계가 문제였던 것일까? 아니면 요구사항이 너무 급진적이었던 것일까?
  - 자세한 테스트 코드를 작성하기 위해 기능적인 구현이 늦춰지는 것이 올바른 것일까? 간단한 테스트만 작성하고 디테일한 부분을 추가하는게 좋다고 생각하지만 실제 코드를 작성하다 보면 설계나 메서드에 대한 방향성이 바뀌는 경우가 많아서 구현 후에 엣지 케이스를 테스트로 작성한는 것이 저와 잘 맞는 것 같다는 생각이 들었습니다.
  - 실무에서 이렇게 한다. 통상적으로 많이 사용된다. (ex. 보통 이 어노테이션을 사용한다. 이렇게 하면 무조건 좋다) 등의 이유로 모든 부분에서 디테일한 부분을 찾아보고 코드를 작성하는 것이 올바른 설계일까? 오버 엔지니어링은 아닐까? 일단 기능을 구현하고 개선점이 생겼을 때 수정하는 것이 좋지 않을까?
  - etc.
- 그래서 제가 과제를 진행하면서 고민했던 내용들을 멘토님과 함께 이야기해보면 좋을 것 같다는 생각을 했습니다.
유틸 클래스와 같이 static 필드로 구성된 클래스의 테스트가 어려웠던 점
- 해당 주제는 RBF에서 다룬 내용입니다.
- 콘솔 유틸 클래스가 static final 필드로 BufferedReader를 갖고 있기 때문에 테스트 시 각 메서드마다 System.setIn()으로 새로운 입력을 지정해줄 수가 없어서 결국 테스트를 위해 해당 클래스의 구현을 변경했습니다.
- 테스트를 위한 기능 구현의 변경이지 않냐? 라는 질문에 그렇다! 라고 할 수 밖에 없지만 추후 콘솔 애플리케이션의 테스트를 위해선 지금 구현 방법을 수정하는 것을 선택했습니다.
- 멘토님과 이에 대해 이야기 해보면 좋을 것 같습니다.
XStreamMarshall가 왜 안되는 걸까?
- 크게 중요한 내용은 아닙니다!
- 강의에서 해당 객체를 사용해서 application/xml 데이터를 반환하는데
- 제가 실제로 적용해보려고 정말 많은 시간을 사용했지만 결국 실패했습니다.
- 결국 다른 방식으로 구현했습니다.
SpringBootApplication은 상위 패키지를 componentScan 하는 것이 왜 안될까?
- 해당 내용도 RBF에서 다룬 내용입니다.
- 3주차 과제에서 사용자 입력에 따라 Console과 Web 애플리케이션을 실행하고 싶다
  - 각자 사용하는 Bean은 하위 패키지에 구현하고
  - 공통으로 사용하는 Bean을 ComponentScan으로 가져오면 되지 않을까?
- main 메서드에서 사용자 입력을 받고 원하는 SpringBootApplication을 실행해보자
  - @SpringBootApplication 의 경우 기본적으로 자신을 포함한 하위 패키지에 대한 ComponentScan을 하기 때문에 상위 디렉토리를 basePackage를 설정해도 빈 등록이 안되는 문제
- main 메서드를 갖고 있는 상위 클래스가 컴포넌트 스캔을 하고 하위 스프링 애플리케이션이 해당 클래스를 import 방식으로 해결
  - 이렇게 하다보니 SpringBootTest에서 Bean Definition과 같은 문제가 발생
  - 하위 스프링부트 애플리케이션에서만 사용하는 빈들을 스프링부트테스트에서 모두 로드하기 때문에 특정 레포지토리가 겹치는 것과 같은 문제
  - 각 컴포넌트에 대해 프로파일 같은 것을 지정해주면 되지만 이는 테스트를 위해 프로덕션에서 불필요한 코드가 추가되는 것 같다고 생각했습니다.
- 멘토님과 같이 코드를 보면서 이야기해보면 좋을 것 같습니다.

ksy90101 · 2023-11-10T13:23:19Z

src/main/java/team/marco/voucher_management_system/VoucherManagementSystemApplication.java

+            case "0" -> ConsoleApplication.main(args);
+            case "1" -> WebApplication.main(args);


상수화로 enum같은걸로 해두면 클린코드 적으로 좋을거 같습니다.

실행할 스프링 애플리케이션의 main 메서드를 enum에서 Consumer로 관리하는 방향으로 수정해봤습니다!

commit 7412a89

ksy90101 · 2023-11-10T13:35:53Z

src/main/java/team/marco/voucher_management_system/facade/VoucherCustomerFacadeImpl.java

-                .map(UUID::toString)
-                .anyMatch(id -> Objects.equals(id, voucherId));
+    public boolean hasVoucher(UUID voucherId) {
+        Optional<Voucher> optionalVoucher = voucherRepository.findById(voucherId);


EXISTQuery랑 이거랑 어떤게 좋을지 한번 고민해보세요!

좋은 고민거리인 것 같습니다!

ksy90101 · 2023-11-10T13:43:59Z

src/main/java/team/marco/voucher_management_system/repository/JdbcCustomerRepository.java

+        Map<String, Object> customerFields = new HashMap<>() {
+        };


Suggested change

Map<String, Object> customerFields = new HashMap<>() {

};

Map<String, Object> customerFields = new HashMap<>()

commit 81d6f1e

ksy90101 · 2023-11-10T13:49:08Z

src/main/java/team/marco/voucher_management_system/web_app/controller/CustomerController.java

+    }
+
+    @GetMapping("/{id}")
+    public String viewCustomerById(@PathVariable("id") UUID id, Model model) {


Suggested change

public String viewCustomerById(@PathVariable("id") UUID id, Model model) {

public String viewCustomerById(@PathVariable UUID id, Model model) {

생략 가능합니다 :)

commit 649f7ff

ksy90101 · 2023-11-10T13:49:30Z

src/main/java/team/marco/voucher_management_system/web_app/advice/ViewAdvice.java

+import team.marco.voucher_management_system.web_app.controller.CustomerController;
+
+@ControllerAdvice(basePackageClasses = CustomerController.class)
+public class ViewAdvice {


500에러 같은 경우에 방어 해놔도 좋습니다 :)

500 에러는 아래 conversation에 있는 VoucherErrorController에서 처리하는 걸 의도해서 우선 다른 부분을 반영해보겠습니다!

ksy90101 · 2023-11-10T13:50:33Z

...ain/java/team/marco/voucher_management_system/web_app/controller/VoucherErrorController.java

+import org.springframework.web.bind.annotation.GetMapping;
+
+@Controller
+public class VoucherErrorController implements ErrorController {


ksy90101 · 2023-11-10T13:51:25Z

src/main/java/team/marco/voucher_management_system/web_app/controller/VoucherController.java

+    public ResponseEntity<Voucher> create(CreateVoucherRequest createVoucherRequest) {
+        Voucher voucher = voucherService.create(createVoucherRequest);
+
+        return ResponseEntity.ok(voucher);


REST API
리소스 생성될때 201 status created를 내려주는데 현재는 200이 내려가네요!

api 명세 규칙을 제대로 지키질 못했네요
감사합니다!

commit 51bfeea

ksy90101 · 2023-11-10T13:52:48Z

src/main/java/team/marco/voucher_management_system/web_app/controller/VoucherController.java

+        if (!isDeleted) {
+            return ResponseEntity.noContent()
+                    .build();
+        }
+
+        return ResponseEntity.ok()
+                .build();


삭제가 안되었다면 에러가 아닐까요?

commit f077d7d

ksy90101 · 2023-11-10T13:53:10Z

src/main/java/team/marco/voucher_management_system/web_app/controller/VoucherController.java

+    @GetMapping("/createdAt")
+    public List<Voucher> findByCreateAt(@RequestParam("from")
+                                        @DateTimeFormat(pattern = DATE_PATTERN)
+                                        LocalDateTime from,
+                                        @RequestParam("to")
+                                        @DateTimeFormat(pattern = DATE_PATTERN)
+                                        LocalDateTime to) {
+        return voucherService.findByCreateAt(from, to);
+    }
+
+    @GetMapping("/type/{type}")
+    public List<Voucher> findByType(@PathVariable("type") VoucherType voucherType) {
+        return voucherService.findByType(voucherType);
+    }


filering같은 경우엔 queryString으로 필터링을 하면 좋을거 같습니다.

commit f949bd9

ksy90101 · 2023-11-10T13:55:27Z

src/main/java/team/marco/voucher_management_system/web_app/dto/CreateCustomerRequest.java

@@ -0,0 +1,6 @@
+package team.marco.voucher_management_system.web_app.dto;
+
+public record CreateCustomerRequest(


springValidate를 한번 써보시면 좋겠습니다~

commit f870b5b, ce79ec0

twotwobread · 2023-11-12T10:03:40Z

src/main/java/team/marco/voucher_management_system/service/VoucherService.java

        return voucherRepository.findAll();
    }
+
+    public Optional<Voucher> findById(UUID id) {


repository.findById 값이 null일 때 raise 하지 않는 이유가 있을까요??

말씀해주신대로 NoSuchElementException을 발생시키고 ControllerAdvice를 통해 noContent Response를 리턴하도록 한 곳에서 관리하는 것도 좋은 방법일 것 같습니다!

제가 해당 코드에서 예외를 발생하지 않은 이유는 아래와 같이 200과 noContent에 대한 분기를 Controller에서 관리하기 위해서 였습니다.

// class VoucherController @GetMapping("/{id}") public ResponseEntity<Voucher> findById(@PathVariable("id") UUID id) { Optional<Voucher> optionalVoucher = voucherService.findById(id); return optionalVoucher.map(ResponseEntity::ok) .orElse(ResponseEntity.noContent() .build()); }

twotwobread · 2023-11-12T10:15:23Z

src/main/java/team/marco/voucher_management_system/service/WalletService.java

+    public List<Customer> findCustomersByVoucherId(UUID voucherId) {
        List<UUID> customerIds = walletRepository.getCustomerIds(voucherId);

        return voucherCustomerFacade.getCustomers(customerIds);


voucher를 가진 customer를 가져오는 의미를 function이 가지면 더 이해가 잘될 것 같습니다.

기능적인 의미만을 생각해서 말씀해주신 부분을 간과한 것 같습니다.
감사합니다!

commit 70a79d9

twotwobread · 2023-11-12T10:22:22Z

src/main/java/team/marco/voucher_management_system/facade/VoucherCustomerFacadeImpl.java

@@ -21,16 +20,14 @@ public VoucherCustomerFacadeImpl(VoucherRepository voucherRepository, CustomerRe
    }


퍼사드 패턴을 꼭 사용해야할까요?? fasade를 이용해서 복잡한 로직을 단순화된 인터페이스로 제공하는 것도 아니고 각 서비스에서의 의존성을 줄여주는 용도도 아니라는 생각이 생각이 들어서 각 서비스 내부에 들어가도 괜찮다는 생각이 듭니다.

확실히 현재 상황에서 퍼사드 클래스는 불필요한 것 같습니다.

2주차 과제에서는 VoucherRepository가 저장과 전체 조회 기능만을 제공했기 때문에 퍼사드 패턴을 사용했지만
commit

join 쿼리와 limit 1을 통해 존재 여부를 판단하는 쿼리를 추가하면 해당 클래스를 제거하고 성능과 구조에 대해 개선할 수 있을 것 같습니다!!

twotwobread · 2023-11-12T10:26:44Z

src/main/java/team/marco/voucher_management_system/facade/VoucherCustomerFacade.java

@@ -6,9 +6,9 @@
 import team.marco.voucher_management_system.model.Voucher;

 public interface VoucherCustomerFacade {


어떤 방향으로 다형성을 이용할 수 있을지 잘 모르겠어서 현재는 해당 인터페이스와 같은 추상화가 필요하지 않을 것 같습니다.

ASak1104 added 30 commits October 30, 2023 22:56

fix : ddl wallet 테이블에 cascade 추가

7494782

refactor : Jdbc 빈 설정과 repository 빈 설정 분리

080148d

test : 조회한 Voucher 정보를 테스트할 때 순서가 상관 없도록 수정

ed2c696

test : save 메서드 테스트에 대한 검증 부분 추가

c8a2b1c

test : 테스트 예외에 대한 검증 부분 추가

9d617ab

test : 블랙리스트 유저 테스트 강화

408969d

test : Voucher 모델에 대한 테스트 강화

c0ef95a

fix : 데이터베이스 커넥션이 없을 때의 버그 수정

5fda05f

fix : 존재하지 않는 고객을 조회할 때 빈 Optional 객체를 반환하도록 수정

1b029d4

test : JdbcCustomerRepository test 코드 추가

0c3f516

test : JdbcWalletRepository 테스트 코드 추가

555b815

refactor : console 애플리케이션 페키지 분리

40e001a

fix : 잘못된 uuid가 입력 됐을 때의 예외처리 추가

383b178

logging : 로깅 포인트 컷 수정

2065a1e

chore : spring web 의존성 추가

641def9

style : 메서드 이름 변경

ae21ab6

feat : voucher 생성 필드 일자 추가

4921225

feat : voucherRepository 조회 추가

3ac74b5

test : voucher 모델 테스트 추가

8ee85f0

test : id, type 조회 테스트 추가

737411b

refactor : string uuid 인자를 UUID 타입으로 변경

fb0987b

chore : javafaker 의존성 추가

57984a2

refactor : voucher 조회 로직 수정

76a4da7

test : VoucherCCustomerFacade 테스트 코드 추가

9a62852

test : 이름과 이메일 생성을 faker 클래스로 변경

2e34c07

refactor : 필요 없는 생성자 제거

eb891a9

feat : Console 유틸 close 메서드 추가

c716997

test : Console 유틸 테스트 코드 추가

6dd746f

fix : 문자열을 변환 방법 수정

5ca617d

test : UUIDConverter 테스트 코드 추가

f4a2123

ASak1104 added 🔥 매운맛 Team-Marco labels Nov 6, 2023

ASak1104 added 14 commits November 7, 2023 09:55

refactor : Voucher createAt을 불변으로 변경

028286d

view : 고객 관리 html 파일 추가

3b66145

feat : 고객 view 기능 추가

3b77085

feat : 고객 관리 ControllerAdvice 추가

b930567

feat : 고객 수정 기능 추가

d5efde3

view : 뷰 파일 위치 변경

6ec6b67

view : 에러 페이지 추가

7a1de11

feat : 고객 삭제 기능 추가

73686fb

test : 고객 테스트 코드 추가

894720c

view : 고객 삭제 버튼 추가

750e944

view : 상세 페이지로 가는 링크 추가

7215e16

test : 콘솔 테스트 기능을 추상 클래스로 분리

9a01773

test : 메인 클래스 테스트 코드 추가

fc515f7

refactor : 콘솔 초기화 메서드를 불변으로 변경

948b2a1

ASak1104 changed the title ~~[5기 - 김현우] Spring Boot Part3 Weekly Mission 제출합니다. (내용 작성 중)~~ [5기 - 김현우] Spring Boot Part3 Weekly Mission 제출합니다. Nov 10, 2023

ksy90101 requested changes Nov 10, 2023

View reviewed changes

twotwobread reviewed Nov 12, 2023

View reviewed changes

ASak1104 and others added 11 commits November 14, 2023 21:42

style : 불필요한 중괄호 제거

81d6f1e

style : 확실한 의미를 내포하도록 메서드 명을 수정

70a79d9

style : 불필요한 param 지정 부분 제거

649f7ff

chore : spring validation 의존성 추가

1332c72

feat : 바우처 생성 dto 데이터 검증 기능 추가

f870b5b

feat : 고객 추가 dto 검증 기능 추가

ce79ec0

refactor : 존재하지 않는 바우처를 삭제할 때 예외가 발생하도록 수정

f077d7d

refactor : 바우처 생성 api의 status 코드 수정

51bfeea

refactor : 실행할 애플리케이션을 이넘으로 관리

7412a89

refactor : 필터링 api를 origin에 대한 쿼리스트링으로 통일

f949bd9

docs: fix typo

d3c86e4

		case "0" -> ConsoleApplication.main(args);
		case "1" -> WebApplication.main(args);

	Map<String, Object> customerFields = new HashMap<>() {
	};
	Map<String, Object> customerFields = new HashMap<>()

	public String viewCustomerById(@PathVariable("id") UUID id, Model model) {
	public String viewCustomerById(@PathVariable UUID id, Model model) {

		@@ -0,0 +1,6 @@
		package team.marco.voucher_management_system.web_app.dto;

		public record CreateCustomerRequest(

		@@ -21,16 +20,14 @@ public VoucherCustomerFacadeImpl(VoucherRepository voucherRepository, CustomerRe
		}

		@@ -6,9 +6,9 @@
		import team.marco.voucher_management_system.model.Voucher;

		public interface VoucherCustomerFacade {

Conversation

ASak1104 commented Nov 5, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

👩‍💻 요구 사항

🚀 애플리케이션 실행

💡 고민했던 점

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ASak1104 Nov 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ASak1104 Nov 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ASak1104 Nov 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ASak1104 commented Nov 5, 2023 •

edited

Loading

ASak1104 Nov 14, 2023 •

edited

Loading

ASak1104 Nov 14, 2023 •

edited

Loading

ASak1104 Nov 14, 2023 •

edited

Loading