spring & 개발환경
프레임워크와 라이브러리 차이점?
📌 제어의 역전 (Inversion of Control)
라이브러리와 프레임워크의 가장 큰 차이는 제어 흐름에 대한 주도성이 누구에게/어디에 있는가에 있습니다. 즉, 어플리케이션의 Flow(흐름)를 누가 쥐고 있느냐에 달려있습니다.
프레임워크는 전체적인 흐름을 프레임워크가 쥐고 있으며 사용자는 그 안에 필요한 코드를 짜 넣으면 되고, 반면에 라이브러리는 사용자가 전체적인 흐름을 직접 만들고 필요에 따라 라이브러리를 가져다가 쓰는 것이라고 할 수 있습니다.
한마디로 프레임워크는 그 틀안에 제어 흐름에 대한 주도성이 내포되어 있고, 라이브러리는 사용자가 전적으로 제어 흐름에 대한 주도성을 가집니다.
⚠️ 프레임워크 : 프레임워크가 흐름을 제어하고 사용자가 만든 코드를 사용 (제어의 역전)
⚠️ 라이브러리 : 사용자가 흐름을 제어하고 라이브러리를 가져다 사용
스프링 프레임워크 구조
- 스프링 삼각형
pojo란?
plain old java object의 약자
객체 지향적인 원리에 충실하면서 환경과 기술에 종속되지 않고, 필요에 따라 재사용될 수 있는 방식으로 설계된 오브젝트를 의미한다.
Ioc(제어의 역행) & Container
container
beanfactory
- bean을 등록, 생성, 조회, 반환 관리
- 일반적으로 이를 확장한 ApplicationContext를 사용
- getBean() method 정의
ApplicationContext
- spring의 각종 부가 서비스를 추가로 제공
IOC 개념
-
객체지향 언어에서 object간 연결 관계를 런타임에 결정
-
객체 간 관계가 느슨하게 연결됨
-
다형성을 통해 낮춤
-
인터페이스 호출 방식
-
구현 클레스 교체가 용이하여 다양한 형태로 변화가능 (다형성)
-
인터페이스 교체 시 호출 클래스도 수정해야함
-
-
팩토리 호출 방식
- 팩토리가 구현 클래스를 생성하므로 클래스는 팩토리를 호출
- 인터페이스 변경 시 팩토리만 수정하면 됨
- but, 클래스에 팩토리 호출하는 소스가 들어가야함, 그것 자체가 팩토리에 의존함을 의미
-
assembler를 통해 낮춤
- Ioc 호출 방식
- 실행시점에 클래스간의 관계가 형성됨
-
의존성주입
빈 생성범위
- 싱글톤 빈
- 스프링빈은 기본적으로 싱글톤으로 만들어짐
- 컨테이너가 제공하는 모든 빈의 인스턴스는 항상 동일함
- 컨테이너가 항상 새로운 인스턴스를 반환하게 만들고 싶을 경우 scope를 prototype으로 설정해야함
스프링 빈 설정
xml
<bean>태그를 통해 세밀한 제어 가능
annotation
- 어플리케이션 규모가 커지고 빈의 개수가 많아질 경우 xml 파일 관리 번거로움
- @autowired 부여해 자동으로 등록 가능
<context:component-scan= base-package/>java configuration file
- @configuration 적용
왜 생성자 주입을 권장하는가?
불변과 누락방지를 보장👍
의존 관계 주입 방법
- 생성자 주입
- 수정자 주입(Setter)
- 필드 주입
- 일반 메서드 주입
1-1 생성자 주입 방식
생성자는 객체가 처음 생성되는 시점에서 호출
단 1회만 호출된다는 특징은 의존 관계의 불변성과 의존관계 필수성으로 연결된다
불변성
무한하게 열려있는 코드보다, 명확한 제약이 존재하는 코드가 본래 목적에 더 충실할 가능성이 크다. 누군가 변경하는 것을 방지한다.
필드 변수에 final을 사용하면, 객체 생성 시점에 초기화가 이뤄져야 한다. 생성자를 이용하여 final 타입을 가진 필드 변수를 초기화하도록 설계하면, 누구든 쉽게 필수 의존 관계를 파악할 수 있다. 가장 빠르고, 명확한 컴파일 오류가 발생하기 때문이다.
1-2 수정자 주입 방식(setter 주입)
필드의 값을 직접 변경하지 않고, setter와 getter 메서드를 사용해 값을 읽거나 수정하는 자바빈 프로퍼티 규악을 이용한다.
클래스에 별도의 public 매서드를 이용하여 의존 관계를 주입한다. public을 사용한다는 점에서 장점과 단점이 발생한다. 언제나 열려있는 public 메서드는 선택과 변경의 가능성이 있는 의존 관계 주입에 필요하다. 반면, public 특성으로 인해 불변성을 보장할 수 없다.
1-3 필드 주입 방식
이름처럼 필드 변수로 직접 주입하는 방법이다. 코드가 간결하다는 장점이 있지만, 외부에서 변경이 불가능하다는 치명적인 단점이 있다. 일반적으로 권장하지 않는 방식이다. 간혹, 애플리케이션의 실제 코드와 관계 없는 테스트 코드를 다룰 때나, 스프링 설정을 목적으로 만드는 @Configuration에서만 한정적으로 사용한다.
1-4. 일반 메서드 주입 방식
수정자 주입과 거의 비슷하나, setter가 아닌 일반 메서드를 이용한다는 차이점이 있다. 한번에 여러 필드를 주입받을 수 있다는 장점이 있지만, 일반적으로 잘 사용하는 방법은 아니다
DI-XML
빈 객체 생성 및 주입
<bean id="" class="" >
<constructor-arg ref=""/> //객체 주입시
</bean>
기본속성
- name : 주입 받을 곳에서 호출할 이름 설정
- id: 주입 받을 곳에서 호출 할 이름 설정(유일값)
- class: 주입 할 객체 클래스
빈 객체 얻기
ApplicationContext context ="ClassPathXmlContext();"
BeanController boardcontroller = context.getBean("board", BoardController.class);- 설정 파일에 설정한 baen을 container가 제공하는 중비기 역할의 api를 통해 주입 받음
DI-Annotation -> java config
<context:component-scan= base-package/>스프링 빈 의존 관계설정
- 필드에 @Autowired
- 동일한 타입의 bean이 여러개일 경우 @Qualifier("name")으로 식별
스프링 빈의 생명주기
