스프링 프레임워크 중요한 용어

@Componet

 

@Component를 추가하면, 클래스와 인스턴스는 스프링 프레임워크가 관리하게 됩니다

다양한 클래스에도 사용이 되며 의존성에도 사용됩니다. @Component는 가장 중요한 어노테이션입니다.

@Component를 사용하고, 해당 클래스가 @ComponentScan에 포함되어 있다면 클래스 인스턴스와 스프링 빈 역시

생성될 것이고 이들을 스프링이 관리하게 됩니다.

 

 

의존성(Dependency)

의존성 주입은 IoC(Invesoin of Control, 의존성 역전) 원칙하에 객체간의 결합을 약하게해주고 유지보수가좋은 코드를 만들어줍니다.     즉, 외부에서 생성된 객체를 이용하는 것입니다.

 

 

@ComponentScan

 

스프링은 컴포넌트가 어디에 있는지 알아야 합니다 스프링 프레임워크에 이를 알리려면 컴포넌트 검색을 통해 알려야하는데  이에 대한 정보는 @ComponentScan를 통해 합니다 @ComponentScan를 통해 패키지명을 명시적으로 정의해줍니다.

@ComponentScan("com.cho.Spring.Framework.coupling.GamingConsole")

만약 패키지명 없이  @ComponentScan을 사용하셧다면 이것이 사용되니 파일이 있는 패키지와 그 하위 패키지를 검색하게 됩니다. 

 

의존성 주입(Dependency Injection)

어플리케이션을 실행할 때 스프링 프레임워크가 하는 것은 먼저 컴포넌트 검색을 합니다. 모든 컴포넌트를 찾아본 뒤에 

이에 대한 의존성이 무엇이 있는지를 확인하고, 이들을 모두 와이어링하는 것입니다. 

이모든 과정이 의존성 주입니다, 

빈확인->의존성확인-> 이를 묶기

이 전체 과정을 의존성 주입이라고 합니다.

관련된 용어가 하나 더 있습니다.

IOC (제어 반전)

작업의 실행과 그 구현을 분리

서로 다른 구현 간에 쉽게 전환

프로그램 모듈성을 높입니다.

컴포넌트를 분리하거나 의존성을 주입함으로써, 컴포넌트가 계약을 통해 소통할 수 있도록해, 프로그램 테스트의 용이성을 높입니다.

 

IOC컨테이너

빈과 의존성이 생명 주기를 관리하는 스프링 프레임워크 컴포넌트 입니다.

이에 대해서는 두종류가 있습니다.

ApplicationContext

다양하고 복잡한 기능을 제공합니다

 

 

 

BeanFactory

기능이 더 간단

 

 

 

AutoWiring

스프링 빈에 대한 의존성을 와이어링하는 과정 전체를 자동 와이어링이라고 합니다.

스프링은 어떤 빈을 확인할 때마다, 이 빈에 필요한 의존성일 무엇인지를 찾으려고 합니다.

 

 

 

 

스프링 @component 와 @bean의 차이점 

 

	Component	@Bean
목적	자동 bean 감지 및 등록에 사용(쉬움)	수동 bean 정의 및 구성에 사용
범위	기본적으로 @Component 빈에는 싱글톤 범위가 있습니다.	@Scope 주석을 사용하여 범위를 정의할 수 있습니다.
구성	@Component에는 추가 구성이 필요하지 않습니다.	메서드를 사용하여 Bean 구성을 사용자 정의할 수 있습니다.
종속성 주입	종속성에 사용할 수 있습니다. 주입	종속성 주입에 사용 가능
사용법	클래스를 빈으로 식별하기 위해 사용 가능	bean을 만들고 구성하는 메서드에서 사용할 수 있음
빈생성	스프링 프레임워크	직접 작성
예제	@Component public class MyComponent {...}	@Bean public MyBean myBean() {return new MyBean();}

대부분의 경우 @component 사용하는것이 대부분 좋습니다.

 

@Bean 은 메소드를 직접 작성하고 빈을 만들어 필요에 의한 스프링 시큐리트를 설정할때 상용하면 좋습니다.

 

빈 생성 전에 자체적인 작업 로직이 많이 사용되는 방식이라면@Bean을 사영하는 것도 가능합니다.

즉 서드 파티 라이브러리를 위해 빈을 생성할때사용 하는것이 좋습니다

스프링 시큐리티를 만들어야 하는데  스프링 시큐리티 코드 접근 권한이 없으니, 코드에 접근해서

@component를 추가하는것이 불가능하기 때문입니다.

 

 

 

스프링 프레임워크가 의존성이 많은 이유

클래스는 거의 없습니다.

어플리케이션은 그렇지 않습니다.

 

맨 처음 게시물에서도 작성을 했지만 다수의 레이어가 있습니다.https://cbh2031.tistory.com/2

스프링 프레임워크의 기본 개념

웹레이어,비즈니스 레이어,데이터 레이어 등등 각 레이어는 그 아래쪽에 있는 레이어에 의존적입니다.

만약 Service Layer 클래스가  Repository Layer의 클래스랑 소통한다고 하면 

 Repository Layer는 Service Layer 의존성입니다. 모든 어플리케이션에, 이런 의존성이 수천 개가 넘습니다.

스프링 프레임워크에서는 객체 자체에 집중하는 대신 그것들의 의존성과 와이어링을 보기 때문에

개발자는 어플리케이션의 비즈니스 로직(service Layer) 부분에 집중하면 됩니다.

 

스프링 프레임워크가 객체의 생명주기를 관장하므로

@Component 어노테이션을 통해 프레임워크가 이를 관리하는 것이고 @Autowired로 의존성을 명시해주는 것입니다.

 

이후의 것은 스픵 프레임워크가 해줄 것입니다. 스프링 프레임워크가 객체를 만들고 의존성을 자동 와이어링해서 

사용할 수 있게끔준비해줍니다