[Spring] Spring CRUD를 마무리하며

🌟 Spring board를 마무리하며

🎯 깃허브 링크

https://github.com/Juhyung990122/Spring_CRUD

🎯 다음 프로젝트에서의 개선점

1. Constructor Injection을 통해 의존성을 주입할 것
본 프로젝트에서는 Field Injection을 사용하여 의존성을 주입했습니다.(@Autowired)
스프링부트의 핵심개념인 DI를 잘 활용하기 위해선 클래스가 독립적으로 인스턴스화(POJO) 할 수 있어야 합니다. 하지만 @Autowired를 사용하게 되면 DI컨테이너와 클래스간의 결합이 생겨서 위의 개념을 위배하게 됩니다.

이와달리 Constructor Injection은 클래스가 독립적이므로 단위테스트에 용이하고(아래 yaboong님 블로그 참고) 순환참조 또한 막아줍니다. 따라서 다음 프로젝트부터는 Constructor Injection을 통해 의존성을 주입할 예정입니다.

2. 객체 생성시 Builder패턴을 사용할 것
본 프로젝트에서는 자바빈 패턴으로 객체를 생성했습니다.
setter메서드를 사용하여 읽기는 좋았으나 setter을 반복적으로 호출한다는 점이 지저분하다고 느꼈습니다.(참고블로그를 보니 생성한 객체에 값을 떡칠한다고 하시는데 왕공감..) 또한 Lombok을 사용하다보니 @setter을 붙이면 모든 필드에 setter가 생겨서 변경하지 않아야 할 필드값도 조작할 수 있게되는게 찜찜했습니다.

이와 달리 builder 패턴은 객체 생성시점에서 값을 전부 넣게 되고, setter을 사용하지 않을 수 있습니다. 또한 build()함수로 객체의 일관성이나 오류를 한번 더 잡을 수도 있습니다.
따라서 다음 프로젝트부터는 Builder패턴을 사용하여 객체를 생성할 예정입니다.

3. Request, Response 에 DTO를 사용할 것
본 프로젝트에서는 Response 에 Entity를 직접적으로 사용했었습니다. 하지만 Entity 클래스는 데이터의 틀이다보니 당연히 너무너무 코어하므로 최대한 직접적인 사용을 지양해야합니다.
수많은 서비스클래스나 로직들이 Entity클래스에서 끌어다 쓰는 형식인지라 Entity에서 하나라도 변경되면 전부를 수정해야하는 그런… 눈물이 앞을 가리는 상황이 벌어집니다.(저도 알고싶지 않았어요…ㅎ…) 또한 서비스마다 다른 Response format을 적용하기도 쉽지않았습니다.

이를 동시에 해결 할 수 있는 것은 Entity클래스와 Request, Response에서 DTO 클래스를 분리하는 것입니다. 따라서 다음 프로젝트부터는 Entity와는 별개의 DTO를 정의하여 사용할 예정입니다.

https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection https://jojoldu.tistory.com/251 https://johngrib.github.io/wiki/builder-pattern/ https://yaboong.github.io/spring/2019/08/29/why-field-injection-is-bad/