Spring(부품을 생성하고 조립하는 라이브러리 집합체)
Java언어를 기반으로 다양한 어플리케이션을 제작하기위한 약속된 프로그래밍 Tool
DI(Dependency Injection)와 IOC Container
외부에서 객체를 생성해 (생성자orSetter)통해 주입
자바 객체 하나하나 bean
<bean id="(unique)" class="package명 포함 class이름을써줌"/> xml문서를 통해 객체생성
<property name="c"> 필드
<ref bean="cal(객체)"> c필드는 cal객체를 참조하고있다
</property>
<property name="fNum" value="10/> fNum필드의 값을 10준다.
xml에서 필드에 값을 정해줄 때 setter함수가 꼭 있어야 한다.
getBean할때("id값","Type(ex:c.class(패키지명제외)")
Interface를 통한 부품화
Spring Property 설정
setter함수들이 존재하기 때문에 이용가능하다.
ArrayList<String> -> <property><list>
MyInfo class 안에 BMICalculator를 참조하여 getBean(객체를 얻어)
IOC Container 객체 하나하나당 (부품) 부품들을 담고 있는 컨테이너
의존 관계
유지보수의 장점
Ex)
AbstractApplicationContext ctx = new GenericXmlApplicationContext(“classpath:applicationCTX.xml”);
Pencil pencil = ctx.getBean(“pencil”,Pencil.class);
pencil.use();
ctx.close();
class가 Pencil4B 이거나 Pencil2B일 때 마다 ctx.getBean(“pencil”,Pencil.class)이름을 바꾼다면 의미가 없다.
클래스를 Pencil이라는 인터페이스로 묶어버린다면 클래스의 변경없이 그대로 사용 가능 하다.
<bean id=”pencil” class=”com.javalec.ex.Pencil4B”/> à <bean id=”pencil” class=”com.javalec.ex.Pencil2B”>
예를 들어 4B class 를 2B로 변경하고 싶을 때 아이디 값은 그대로 둔 채로 클래스이름만 달리하여 유지보수에 용이성을 높일 수 있다.
l Java파일의 수정 없이 스프링 설정 파일만을 수정하여 부품들을 생성/조립 가능하다.
LifeCycle 과 범위
Spring 컨테이너 생명주기
스프링 컨테이너 생성 --> GenericXmlApplicationContext ctx = new GenericXmlApplicationContext()
(parameter 없는 default생성자를 만들 시에는 load/refresh
스프링 컨테이너 설정 à ctx.load(“classpath:applicationCTX.xml”) / ctx.refresh();
스프링 컨테이너 사용 à Student student =ctx.getBean(“student”,Student.class);
스프링 컨테이너 종료 à ctx.close();
스프링 빈 범위(Scope)
스프링 컨테이너가 생성되고 , 빈이 생성될 때 생성된 스프링 빈은 scope(범위)를 가지고 있다.
범위란 쉽게 생각해서 해당하는 객체가 어디까지 영향을 미치는지 결정하는 것이라고 생각하면 된다.
메모리 구조를 잘 생각해보면 된다.
Student student1 = ctx.getBean(“student”,Student.class);
Student student2 = ctx.getBean(“student”,Student.class);
bean에서 이미 객체를 생성하고getBean을 이용해 1,2변수에 담은 것 뿐이다.
<bean id=”student” class=”com.javalec.ex.Student” scope=”singleton”>
AOP란?
프로그래밍을 하다보면 , 공통적인 기능이 많이 발생한다.
이러한 공통 기능을 모든 모듈에 적용하기 위한 방법으로 상속을 통한 방법이 있다.
상속도 좋은 방법이기는 하지만 몇 가지 문제가 있다.우선 JAVA에서는 다중 상속이 불가하므로 다양한 모듈에 상속기법을 통한 공통기능 부여는 한계가 있다. 그리고 기능 구현부분에 핵심 기능 코드와 공통 기능 코드가 섞여 있어 효율성이 떨어진다.
위의 상속을 통한 방법에 한계가 있어AOP가 등장하게 되었다.
AOP방법은 핵심기능과 고통기능을 분리시켜 놓고 공통기능을 필요로 하는 핵심 기능 들에서 사용하는 방식이다.
*공통 기능을 핵심 기능과 분리해 놓고, 공통 기능 중에서 핵심 기능에 적용하고자 하는 부분에 적용한다.
Apspect : 공통 기능
Advice : Aspect의 기능 자체
JointPoint : Advice를 적용해야 되는 부분 (ex, field ,method) 스프링에서는 메소드만 해당
Pointcut JointPoint의 부분으로 실제 Advice가 적용되는 부분
Weaving:Advice를 핵심 기능에 적용하는 행위
스프링에서 AOP구현 방법: Proxy를 이용한다.
호출부 - > Proxy(대행) -> Target(핵심기능)
Proxy에 공통기능을 넣어주면 알아서 수행 하고 돌아온다.
AOP구현 방식 - XML Schema 기반 / @Aspect annotation 기반
'Spring' 카테고리의 다른 글
[Spring] 기본2 (0) | 2018.11.27 |
---|---|
[Spring] 요청 URI 매칭 (0) | 2018.11.27 |
[Spring] @RequestBody / @ResponseBody (0) | 2018.11.27 |
[Spring] ViewResolver (0) | 2018.11.27 |
[Spring] @Autowired / @Service (0) | 2018.06.27 |