HwangHub

프로젝트를 진행하면서 각 도메인의 작업물을 stage 브랜치로 merge하고 나니 팀원 중 한 명이 필드 인젝션을 사용한 것을 확인할 수 있었다. 본능적으로 "어라? 왜 생성자 인젝션을 사용하지 않았지?"라는 생각이 들었는데, 스스로 필드 인젝션의 위험성에 대한 이유를 명확히 댈 수 없음을 깨달았다. 따라서 이번 기회에 정리하고자 한다. 의존성 주입 방법 3가지 스프링부트를 활용하면서 의존성을 주입하는 방법은 대표적으로는 3가지가 있다. Setter 주입 생성자 주입 필드 주입 이는 @Autowired 어노테이션을 Setter, 생성자, 필드에 선언해주는 것으로 구현한다. 따라서 이 방법들을 알아보기 전에 @Autowired 에 대해 간단하게 짚고 넘어가고자 한다. @Autowired란? docs.spr..

어플리케이션 성능 모니터링 어플리케이션 성능 모니터링(APM)은 어플리케이션의 성능을 실시간으로 모니터링할 수 있도록 해주는 도구입니다. 이를 통해 개발자는 어플리케이션의 성능을 실시간으로 확인하고 분석할 수 있습니다. Spring Boot Actuator : 스프링 부트 어플리케이션의 상태를 모니터링하고 관리하는 데 사용되는 모듈입니다. Actuator를 사용하면 어플리케이션의 상태, 메트릭, 빈, 스레드 등을 확인할 수 있습니다. Actuator는 spring boot starter에 등록되어 있습니다. 그 외에 Micrometer와 같은 모니터링 시스템 구현체도 있습니다. 로깅 및 로그 분석 어플리케이션 로그는 어플리케이션의 동작과 관련된 중요한 정보를 담고 있습니다. 로그를 효과적으로 관리하고 분..

AOP를 통해서 Validation을 구현하던 중, 해당 코드를 원래 Controller에서 작성하고, 검증하고 있었음을 이해하게 되었다. Dto에 해당 조건들을 걸고 난 뒤에는, Controller에서 Validation을 체크하고, 문제가 없을 경우 Service로 내리는 흐름으로 돌게 되어 있다. 상황을 가정해보자. 아래와 같이 Entity가 정의되어 있다. @Entity @Getter @Table(name = "user_tb") @NoArgsConstructor(access = AccessLevel.PROTECTED) public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(..

스프링 프레임워크는 객체 생성자를 DI를 위해 IoC 컨테이너에 등록해서 사용하는데, 이때 컨테이너에 등록하는 객체나 그 생성자를 Bean이라고 하며, Bean으로 관리한다는 말을 한다. 이렇게 스프링에 필요한 Bean을 '직접' 등록하기 위해서는 @Bean 어노테이션을 사용할 수 있지만, 우리는 보통 @Service, @Repository와 같은 어노테이션을 활용하여 자동으로 IoC 컨테이너에 Bean을 등록한다. 스프링은 '컴포넌트 스캔' 과정을 통해 @Component가 선언된 클래스를 Bean으로 등록한다. 우리에게 익숙한 @Controller, @Service, @Repository, @Configuration 모두 그 상위에 @Component를 가지고 있다. 스프링이 Bean으로 관리하는 것..

많은 이들이 김영한님의 JPA 강의를 시작으로 스프링 첫걸음을 떼기 때문에, 자연스럽게 엔티티 모델링을 진행할 때 wrapper class를 사용하는 것이 익숙할 겁니다. 하지만 한번쯤은 고민해볼 필요가 있는 것이 wrapper class 사용의 이유 입니다. 왜 우리는 지금까지 wrapper class로 필드를 구성해온 것일까요? Wrapper class wrapper class는 자바가 기본적으로 제공하는 원시 타입의 자료형을 '객체'로서 사용하기 위해 고안된 클래스입니다. 여기서 우리가 주목해야 할 차이점은 wrapper class는 초기화하지 않으면 null이 되지만, 원시 타입은 0과 같이 기입된다는 점입니다. 즉, 원시 타입으로 엔티티 필드를 구성하면 null 가능성이 아예 차단되는데, wra..

우리가 프로젝트를 진행할 때, 로컬 환경에서 테스트할 때와 개발 단계에서 프론트엔드와의 협업을 위해 개발 서버에 배포할 때나, 그리고 실제 릴리즈를 진행했을 때 모두 그 실행 환경이 다른 경우가 많다. 따라서 스프링에서는 이를 "프로파일 분리"라는 개념으로 환경 설정을 구분하여 적용할 수 있게 하였다. 근데 이게 스프링부트 버전업이 진행됨에 따라, 2.4버전에서 급격하게 변화가 있었나보다. 단적인 예시로, 이전에는 spring.profiles 또는 include를 이용하여 프로파일 설정을 하였다고 한다. 나는 미래를 살아가는 개발자로서, 굳이 deprecated된 기능을 연구해볼 필요는 없을 것 같고, 현재 어떻게 활용할 수 있는지만 보려고 한다. (물론 과거의 패턴 또한 알면 좋지만, 내가 지금 알아야..