DI구조
- 컨테이너에 빈들 등록
- injection 방법으로 의존관계 형성
- 생성자 주입
- setter 주입
- 어플리케이션의 시작지점(entry point)에 컨테이너 객체 생성
- 설정파일 넘기기.
- 어느 리소스인지 정적으로 고정되있지 않고 동적으로 바뀐다면 generic으로
- 빈 검색할 수 있는 조건 - 타입, id
빈 관리
- 싱글턴
-싱글턴의 대상은 클래스가 아니라 빈이다. - session에 memberVO담는데 그게 싱글턴으로 운영되면 어떤 사람이 로그인하든지 하나의 객체로 운영됨
이럴때는 주입 받을때마다 만들어야됨- protoType설정 - lazy, prototype은 둘다 객체 생성시점을 뒤로 미루지만 prototype은 주입할때마다 생성
- 객체 생성 순서 제어 : depense on
순환구조가 발생하면 안됨(a->b->c->a : 아무것도 생성안되고 계속 기다리기만 해야됨) - 컨테이너를 통해 라이프사이클 관리할때 빈이 생성됬다, 없어졌다 필요할때 콜백메소드 사용
컬렉션
- properties
: 다른 컬렉션과 다르게 인메모리가 아니라 외부에 파일 형태로 관리가능 - 로드메서드.이걸로 파일읽어서 가져옴
-> location필요
내부에 빈이 등록되는 것. 그래서 id가 필요properties 값들을 가지고 있는 객체라고 생각하면 되나?
concat연산 지원함
jstl - 속성명 spel - id가 사용된다.
spring system안에 기본적으로 프로퍼티 소스가 존재. 그 안에 추가적으로 집어넣고 싶을때 사용하는게 property-placeholder
추가적으로 넣는게 기존에 있는 프로퍼티명이랑 겹치지 않게 넣는게 가장 중요.
연산 지원하지 않음
-> 우리만의 prepix 붙여줌
얘는 클래스패스가 아님
navigationview에서 target이 진짜 클래스패스
이클립스는 비어있는 폴더는 배포할때 버림
SrarCraft
- 템플릿 패턴 적용
후크 메서드 : walking(), withWeapon()
템플릿 메서드 : attack();
- 전략패턴 사용
전략을 고정하지 않겠다가 핵심. 런타임시에 필요한거 다 갔다 쓰겠다.
- 팩토리 객체
컨테이너 내부에 있는 빈들한테 컨테이너 자체에 대한 레퍼런스 넣어주는게 가능
인트페이스로 가능하게 함
현재 돌아가고 있는 컨테이너를 넣어준다.
auto DI
injection 자동으로
이 어노테이션들이 마커어노테이션들이 되는것.
스프링이 어노테이션보다 먼저 나옴.
어노테이션 쓸건지 안쓸건지 설정
얘가 반드시 필요
하지만
얘는 annotation-config 포함하고 있음.
이거 안쓸때만 어노테이션컨피그 설정해주면됨.
어노테이션-시스템, 사람에게 알려주는것
어노테이션 여러개 쪼개진것은 사람을 위한것
나머지 세개는 빈으로 등록한다는 것만 의미. service에 @Repository붙여도 상관없음
하지만 @Controller는 핸들러라는것까지 알려주는것!
빈의 id-싱글벨류. 생략하면 COC
특정레이어에 속하지 않는데 필요할때. 모호할때
@Component어노테이션 사용
private을 public으로 바꾸고 주입함. 리플렉션으로 access가 가능한 상태로 만들고 주입함. -> 생성자, setter없어도 주입가능함. 하지만 정석은 아님
field
setter
pojo로 만드려면 resource써야됨. 하지만 auto가 편할때도 있음. -> 자바진영에서도 만들었을것
Inject
얘는 jar추가해서 사용해야됨.
스프링과 연관성 없음. 스프링진영에서도 auto 쓰지말고 얘 쓰라고 함.
@Requiered
setter로 하면 셋터 호출하기전까지 문제가 있어도 모름.
그래서 반드시 setter를 호출해야된다는 어노테이션
xml말고 자바방법설정
스프링 4점대에는 자바config방식 만들어짐.
구글 스프링 찾아보면 거의다 자바방식
하지만 우리나라는 xmlconfig방식이 대세
자바파일을 컨피그파일로 쓰겟다 - @Configuration
web 사용하기 위해 집어넣어야됨 - web.servlet.
근데 이름은 web.mvc임
maven - 디팬던시 제공, 틀 만들어줌
그 틀 쓸건지 물어보는것
이것들 알아서 넣어줌.
리스너 이용해서 상위 컨테이너 만들어지고
서블릿이용해서 자식 컨테이너에 만들어짐
-> 공통으로 쓰는거는 부모xml에 만들어야된다.
이 DispatcherServlet-frontcontroller
공통빈 중복 제거하기위해 계층구조 이용하는 것.
web에 종속되는 애들과(얘네는 요청을 받고 처리해야되니까 req, resp에 종속됨) - 하위
web과 상관없는애들. service, dao들은 web에서도 쓸수있고 standalone에서도 사용가능 - 상위
model안에 넣은거 h.a가 req에 그대로 넣음
파일처리할때 필터가 먼저 처리했는데 스프링은 front뒤에 처리함.
wep 버전 2.5라 Part못씀 -> commons의 fileupload사용
필터를 front 바깥이 아니라 안쪽에 등록해서 써먹으면됨
@Component는 모든 anotation보다 먼저만들어짐
나머지는 얘 위에 만들어짐(어노테이션은 상속 안되서 service어노테이션 만들때 @Component 추가해서 만들어서 @component를 inclue하면 나머지 어노테이션 가지고 있는 것도 include됨
웹어플리케이션은 엔트리포인트가 명확하지 않아서 이벤트로 처리
톰캣의 web.xml에 얘가 등록되고 있어서 톰캣이 정적자원 처리할 수 있었던 것.
이렇게 매핑되있어서 내가 루트를 /잡으면
스프링에서 정적자원 처리 해줘야됨. 내가 톰캣거 뺏은것.
!!루트를 /로 잡을땐 정적자원 처리에 대한것 생각해야된다.
body영역 안에 또다른 디코딩 설정하고 있다면 그거 따라갈건지 설정하는것. 필터는 순서가 있는데 뭐가 먼저될지 모르니까.
true - 내가 설정한걸로 강제
dispatcher Servlet은 논리적인 뷰 네임 받아서 어떤 리졸버로 보낼지 결정해야됨. 그때 중요한게 순서. 우리껀 h.b, h.a
InternalResourceViewResolver는 자기가 못찾으면 무조건 404내보냄.
-> 뷰리졸버가 몇개든 맨마지막이어야됨.
-> order를 안줌. - 기본값 사용됨(integer로 줄수있는것중에 가장 큰값)
