Spring - Spring Etc Study

직접 인터페이스 = new 구현체 방식으로 하니까 OCP에 위반하게 되었다.
OCP도 지키고, IoC 와 DI를 지키기 위해 AppConfig 라는 것을 만들어서 의존관계를 외부로 돌렸다.
그러나 싱글턴 문제가 발생하였고, 매번 싱글턴으로 만들어 줄 수 없기 때문에 Configuration과 Bean을 통해 스프링 컨테이너에 등록하여 관리해주었다. ( 여전히 Bean이 붙은 메서드에서 의존관계를 주입하였다. )
@ComponentScan과 @Component를 통해, @Component가 붙은 모든 클래스를 스프링 컨테이너에 자동으로 등록하였고, @Autowired를 통해 자동으로 의존관계를 주입하였다.

우리가 스프링 부트를 만들면 처음에 @SpringBootApplication 이라고 어노테이션이 붙은 시작 클래스가 있다.
해당 어노테이션을 들어가보면 @ComponentScan이 있다. 그래서 우리는 사실 스프링 부트를 만들면 시작부터 컴포넌트 스캔이 있는 것이다.

@Component @Controller @Service @Repository @Configuation 안에는 @Component가 있음. 그래서 @Component 효과가 생김.
그럼 왜 저렇게 바꿔서 쓰나?
- 명시적인 이유도 있지만, 메타정보 효과도 있다.
- @Controller 스프링 MVC 컨트롤러로 인식
- @Repository 스프링 데이터 접근 계층으로 인식 / 데이터 계층의 예외를 스프링 예외로 변환 ( 즉, A DB에서 B DB를 쓰다 예외가 생겨서 Service의 try catch의 예외 선언이 흔들리면 안되니 추상적인 스프링 예외로 변환해서 반환함. )
- @Service 특별한 처리는 없음. Component와 가장 유사함. 대신 Service 계층임을 명시적으로 해주기 위해 사용
- @Configuration 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 해줌.

업무 로직은 자동빈, 기술 지원 로직은 수동빈으로 하는게 좋다.
- 업무 로직 : Controller Service 등
- 기술 지원 로직 : Sequrity Redis 등
그러나 업무 로직중에서도 다형성을 적극 지원해야 하는 경우가 있는데 ( 할인 설정 정보 등 ) 그런 경우에는 Configuration을 하나 만들어서 Bean으로 등록하는게 좋을 수도 있다. ( 고민 )
또한 스프링과 스프링부트가 자동으로 지원하는 수 많은 빈들이 있는데 이건 메뉴얼을 잘 참고해서 스프링 부트가 의도한 대로 편리하게 사용하는 것이 좋다. ( DataSource 등 )

우리가 AWS에 애플리케이션을 올린다면 그것은 AWS로부터 자원을 할당받은 프로세스가 된다.
그리고 거기에 접근하는 다른 유저들 하나하나가 스레드가 된다.
Spring 의 경우 Spring 컨테이너로 인해 Bean 등록이되면 초기화가 되므로, 일단 한 번은 실행되면서 전부 JVM 클래스 로더에 의해 Runtime Area에 들어간다.
그래서 static 블럭을 사용하게 되면, 최초 한 번만 작동하는 것이므로. Bean 등록 때 동작해버린다. 그래서 static 블럭은 잘 사용하지 않는다.

results matching ""