[Spring] Spring Framework 의 개요 #3

Spring Framework 의 개요 #3

Spring의 IoC

Spring Bean ( 그냥 Bean 이라고도 부름 )

Spring Container 가 생성과 관계설정, 사용 등을 제어하는 IoC가 적용된 object.

Bean Factory 확장한 Application Context

별도의 정보를 참고하여 Bean의 생성, 관계 설정 등의 제어작업을 총괄

코드에 상세내용이 들어가는 것이 아니라 설정정보를 가진 별개의 파일(xml)을가져와 활용하는 범용 IoC 엔진

Annotation Config Application Context

@Configuration

Factory class 에 붙는 annotation

@Bean

Object 만들어 return 하는 method.

예제코드

ApplicationContext context = new AnnotationConfigApplicationContact( DaoFactory.class );

UserDao dao = context.getBean( "UserDao", UserDao.class );

Application Context 의 동작방식

IoC Container, Spring Container, Bean Factory 모두 Application Context 를 지칭하는 단어.

cf) getBean 은 등록된 List 해서 해당 Bean 이름을 검색하여 return 해주는 방식이다.

IoC Container 를 사용하면 범용적이고 유연한 방법으로 IoC 기능 확장이 가능하다.

1. Client 는 구체적인 factory class 를 알 필요가 없다.

확장시 factory 가 늘어나고, facotry object 도 추가 생성해야 한다.

application context 를 이용하면 factory 가 많아져도 이들에 대해 몰라도 된다.

일관된 방식( xml ) 으로 object 를 가져올 수 있다.

2. Application Context 는 종합 IoC 서비스 제공

이놈은 단지 생성과 관계설정 뿐만 아니라 Object 의 생성방식, 후처리, 정보의 조합, 설정방식의 다면화, 인터셉팅 등 object 를 효과적으로 활용할 수 있는 다양한 기능을 제공하다.

3. 빈을 검색하는 다양한 방법 제공

이름을 통한 getBean() 뿐만 아니라, type으로 검색, 특수 annotation Bean 검색 등도 제공해준다.

Object의 동일성과 동등성

identical ( == ) 과 equivalent ( equals ) 는 다르다.

identical 은 동일한 녀석이고, equivalent 는 내용물이 같은 녀석이다.

Application Context 는 Singleton Registry

별다른 설정이 없으면 내부에서 생성하는 빈 오브젝트는 싱글톤으로 만들어진다.

왜? Spring 은 태생적으로 enterprise system( 서버 )를 위해 고안되었다.

서버는 초당 엄청난 양의 request 를 받아 처리하는데, 이 때마다 new 로 새로운 object 들을 만들면 gc 성능이 아무리 좋아도 부하를 감당하기가 힘들다.

그래서 enterprise 분야에서는 service object 개념을 일찍부터 사용. ( 예: servlet )

Singleton Pattern

비판이 많다. 매우 조심해서 사용해야 한다.

어떤 Class나 App 내에서 제한된 instance(보통 1개)만 존재하도록 강제하는 방식.

전역적으로 접근해서 단일 object 를 공유해서 사용.

Singleton Pattern 의 문제점

1. private 생성자라 상속이 불가능하다. 

이는 객체지향 특성을 무시하는 행위이며, 추가적으로 static 을 사용한다.

2. 테스트하기가 힘들거나 아예 불가능하다.

Mock Object 등으로 대체하기가 힘들다.

초기화 과정시 생성자를 통해 사용할 object 를 dynamic 하게 주입하기도 어렵다.

3. 서버환경에서 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.

ClassLoader 구성에 따라 singleton 유지가 안 될 가능성이 있다.

여러개의 JVM 에 분산설치 되는 경우도 마찬가지이다.

4. 전역상태를 만들어 바람직하지 않다.

객체지향에서 지양해야 할 것.

Singleton Registry

Spring Container 는 Singleton을 생성, 관리, 공급하는 싱글톤 관리 container

Static method 와 private 생성자를 사용하지 않아도 singleton을 유지할 수 있다.

Framework 가 이를 cover 해주니 앞서 발생하는 singleton pattern 의 문제점을 커버해준다.

Singleton과 Object의 상태

Singleton은 multi thread 환경에서 stateless 여야 한다.

그럼 state 관리가 필요한 경우는 어찌하나?

parameter, local value, return 등을 활용해서 구현 가능하다.

method 안의 local 변수는 singleton 이어도 매번 새로운 값을 지정할 수 있는 독립메모리 공간이 만들어져서 ok.

instance 변수는 읽기 전용이어야 한다.

Spring Bean's Scope

* 기본은 singleton scope

* 요청에 따라 prototype scope 가능. 이는 요청할 때마다 새로운 object 를 만든다.

* HTTP 요청이 생길 때마다 생성되는 request scope 도 있다.

* 웹의 session과 유사한 session scope 도 있다.

==, @bean, @configuration, annotation bean, annotation config application context, application context, BEAN, bean factory, bean 생성, ClassLoader, enterprise, equals, equivalent, factory 확장, GC, getBean, identical, IOC, ioc container, jvm, local value, mock object, multi thread, new, parameter, private 생성자, prototype scope, request scope, Return, Scope, servlet, session scope, Singleton, Singleton Pattern, singleton registry, singleton scope, Spring, spring bean, spring container, Spring Framework, Stateless, static, test, xml, 개요, 관계 설정, 동등성, 동일성, 빈, 생성, 스프링, 스프링 빈, 스프링 콘테이너, 스프링 프레임워크, 싱글톤, 싱글톤 패턴, 읽기 전용, 테스트