- 굳이 DI를 적용하지 않았더라고 자신이 사용하는 오브젝트의 클래스가 어떤 것인지 알지 못하게 만드는 것이 좋음
- 인터페이스는 여러개 구현 가능하다(extends와 달리) ->
같은 타입으로 존재하지만 다른 구현을 가진 오브젝트를 만들 수 있음 (다형성) - 자기참조 -> 스프링은 property 태그의 ref 항목에 자기 자신을 넣는것을 허용
- OXM -> XML과 자바 오브젝트를 매핑해서 상호 변환해주는 기숭
- 스프링이 제공하는 OXM 추상화 인터페이스
Marshaller : 자바 오브젝트 -> XML
Unmarshaller : XML -> 자바 오브젝트 - CastorXML -> 매우 간결하고 가벼운 바인딩 프레임워크
- 스프링 Resource 인터페이스 -> 자바에 존재하는 일관성 없는 리소스 접근 API를 추상화해서 Resource라는 추상화 인터페이스를 정의함
스프링에서 bean이 아닌 값으로 취급함. - ResourceLoader -> 문자열 안에 리소스의 종류와 리소스의 위치를 함께 표현 -> Resource 타입 오브젝트로 변환해줌
- 애플리케이션 컨텍스트가 구현해야하는 인터페이스인 ApplicationContext 는 ResourceLoader을 상속함 -> 모든 ApplicationContext 는 ResourceLoader 임
- 설정 정보가 담긴 XML 파일도 ResourceLoader 릏 통해 Resource 형태로 읽어오고 value="file:..." , value="classpath:..." 같은 값들도 Resource 형태로 변환
- classpath: 클래스패스 루트로부터 상대적인 위치
- file: 파일 시스템의 루트 디렉토리로부터 시작하는 파일 위치
- http: 웹 리소스
- 스프링 애플리케이션에서 파일을 읽거나 참조하는 기능을 만들 때는 Resource타입의 추상화 기능을 사용하자
아직 배우는 중입니다