나 혼자만 개발업

컴포넌트 스캔과 의존관계 자동 주입 등록해야 할 빈(@Bean)이 몇백 몇천개라면? 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔 기능을 제공 의존 관계도 자동 주입하는 @Autowired도 제공 @ComponentScan 자동으로 스프링 빈을 끌어올리는 에너테이션 즉 자동으로 스프링 빈을 등록해줌 이 에너테이션은 @Component 에너테이션이 붙은 클래스를 모두 스캔해서 스프링 빈으로 등록 @ComponentScan( excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class) ) 스프링 빈을 자동 등록하는데 필터링 할 것을 지정 컴포넌트 스캔을 지정하면 @..

생성자 주입을 선택해야 하는 이유 최근에 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 불변성 대부분의 의존 관계 주입은 한번 일어나면 종료시점까지 의존관계를 변경할 일이 없음. 또한, 오히려 의존 관계는 애플리케이션 종료 전까지 불변해야 한다. (변경이 적어야함.) 수정자 주입은 setter를 public으로 열어 두어야 하기 때문에 외부에서 변경 가능성이 있음. 생성자 주입은 객체 생성 시 단 1번만 호출 되므로 불변하게 설계할 수 있음. 누락의 방지 생성자는 호출 시 필수적으로 값을 초기화해주어야 하므로, 누락을 방지할 수 있다. 또한 필드에 final을 붙여서 생성자에서만 초기화가 가능해지고 필드의 값이 final이므로, 불변성이 된다. 이 뿐만 아니라, 필드에 final이 붙..

@Autowired의 옵션처리 @Autowired는 required default가 true이므로, 자동 주입 대상이 없으면 오류가 발생 자동 주입할 대상이 없으면 null이 됨. 처리 방법 @Autowired(required = false) required 는 필수 주입 여부를 결정하는 옵션. false로 하는 경우, 제외 대상이 될 수 있음 @Nullable 이것을 파라미터에 넣어주면 null로 처리를 해줌. Optional Optional.empty로 넣어줌 public class AutowiredTest { @Test @DisplayName("Autowired의 옵션 처리") void AutowiredOption() { ApplicationContext ac = new AnnotationConfi..

의존관계 자동 주입 스프링의 두 가지 라이프 사이클 빈 생성 단계 의존 관계 주입 단계 의존 관계의 여러가지 주입 방법 생성자 주입 수정자 주입(setter) 필드 주입 일반 메서드 주입 생성자 주입 ( 가장 많이 사용되는 주입 방식 ) @Autowired, 생성자에 이 에너테이션을 붙여서 생성자의 정보를 토대로 의존 관계를 주입 생성자 호출시점에 딱 1번만 호출되는 것이 보장됨. 즉, 코드만 잘 짜면 1번만 호출하여 의존 관계를 주입하고 더 이상 세팅 못하게 막는 것이 가능하다. 따라서, 불변, 필수 의존관계에 사용된다. 수정이 적은 불변성 코드를 작성하는 것이 개발에서 좋은 습관이다. 불변, 필수 의존 관계란?? final이 붙은 필드는 값이 무조건 초기화되어야 하며, 값이 할당 되면 "불변"이다. ..

Redirect Controller의 request handler 메소드의 리턴이 void(또는 null)리턴이면 view의 이름으로 해석된다. String이면 view의 이름으로 해석되며, 'redirect:'라는 접두어가 붙으면, 응답코드가 302이고, location 응답 헤더의 값이 접두어 이후의 값으로 세팅 RedirectAttributes Spring 프레임워크에서 리다이렉션 후, 데이터를 전달하는 데 사용되는 인터페이스 주로 POST 요청을 처리 후, 사용자를 다른 URL로 리다이렉션하면서 데이터를 유지하고 싶을 때 유용하다. addAttribute() - 메서드 이 메서드를 사용하여 데이터를 파라미터 쿼리에 추가시킨다. addFlashAttribute() - 메서드 이 메서드..

참고 - 2023.09.26 - [Spring] - SOLID 원칙 :: 관심사의 분리와 DI컨테이너 앞서 포스팅한 글에서 순수 Java코드로 SOLID 원칙에 따라 객체 간의 관심사를 분리시켜 추상화에만 의존하도록 클라이언트 코드를 설계하고, 애플리케이션 동작을 위해 객체 간의 의존성을 연결해주는 DI컨테이너에 대해 서술해보았다. 즉, 각 구현체들은 추상화에만 의존하므로 다른 구현체에 대한 존재를 모르고 자신의 로직만을 수행하고, 프로그램의 전반적인 제어 흐름을 DI컨테이너가 담당한다. 이와 같은 흐름으로 프로그램의 제어를 프로그래머가 직접 하는 것이 아니라 외부에 의해서 관리되는 것을 '제어의 역전(IoC)'이라고 말한다. 그렇기 때문에, DI 컨테이너를 'IoC 컨테이너'라고 부르기도 한다. 순수 ..

참고 - 2023.09.25 - [Java] - 객체 지향 설계의 기본 :: 역할과 구현의 분리 SOLID 원칙 SOLID원칙이란 좋은 객체 지향 프로그래밍을 설계하기 위한 기본 원칙으로, 여러 소프트웨어 엔지니어들과 클린 코드로 유명한 로버트 마틴이 제안한 개념이다. 이 원칙은 객체 지향 프로그래밍에서 유지보수성이나 확장성, 재사용성 등 다양한 측면에서 효율적인 시스템을 설계할 수 있도록 지침을 제공하는 중요한 개념이다. SOLID는 다음과 같이 다섯 가지 원칙으로 구성된다. 1. 단일 책임 원칙 - SRP(Single Responibility Principle) SRP원칙은 하나의 객체는 하나의 책임만 가져야 함을 의미한다. 여기서 책임이란, 클래스가 프로그램 내에서 수행하는 역할 또는 기능이라고 말..

스프링의 도입 스프링 도입 이전, JAVA 엔터프라이즈 애플리케이션 개발을 위해 EJB(Enterprize JavaBeans)라는 표준 컴포넌트 모델을 사용했었다. 초기 EJB는 매우 복잡한 API와 설정, 성능 문제 등 많은 문제가 있어, 개발자들이 개발하는 데에 많은 어려움을 겪었다. EJB3.0부터는 더 간단하고 가벼운 프로그래밍 모델을 제공하며 개발자 경험을 대폭으로 개선했으나, 2003년 로드 존슨(Rod Johnson)이 개발한 경량 프레임워크인 스프링과 경쟁하면서 EJB의 인기가 감소하게 되었다. 스프링(Spring) 스프링은 자바 기반 애플리케이션을 개발하기 위해 다양한 기술들을 제공하는 프레임워크이다. 핵심 기술 스프링 DI 컨테이너 : 의존성 주입(Dependency Injection)..