토비스프링

기본 생성자 (툴이나 프레임워크에서 Reflection을 이용해 생성하기 때문에 필요)프로퍼티 (Getter, Setter 메소드로 수정, 조회)JVM이 프로그램을 실행할 때 클래스 파일을 찾는 기준이 되는 경로중복 제거는 말 그대로 중복되는 코드를 메서드 등으로 빼놓

BeanFactory를 상속받는다.별도의 설정 정보를 이용해 빈의 생성, 관계 설정 등의 제어 작업을 총괄각 프로젝트 폴더를 조립 (가상 배포 공간에 배포)오브젝트 생성을 위한 IoC용 메서드라는 것을 명시ApplicationContext의 getBean("메서드 이름

DataSource 인터페이스의 getConnection() 메서드로 DB 커넥션을 불러올 수 잇음.단위테스트 -> 기능 단위로 테스트. 단위가 작을수록 좋음테스트 주도 개발 (TDD) -> 테스트 우선 작성 후 코드를 작성하는 개발 방식. 이렇게 하게 되면 코드 작성

테스트를 할 때는 데이터를 경계가 되는 값의 전후로 선택하는 것이 좋음ex) 10 이면 9, 11 이런식으로객체지향적인 코드 -> 다른 오브젝트의 데이터를 가져와서 작업하는 대신 그 데이터를 갖고있는 다른 오브젝트에게 작업을 해달라고 요청여러 클래스에서 반복되는 값은

스프링은 지정된 클래스 이름을 가지고 리플렉션을 이용해서 해당 클래스의 오브젝트를 만듦.\* Class의 newInstance() - > 기본 생성자 호출 후 오브젝트 돌려줌 (빈이 기본생성자가 있어야 하는 이유)Factory Bean -> 스프리을 대신해 오브젝트의

TransactionDefinition 인터페이스 -> 트랜잭션의 동작 방식에 영향을 줄 수 있는 네가지 속성을 정의Transaction Propagation -> 트랜잭션의 경계에서 이미 진행중인 트랜잭션이 있을때와 없을때 각각 어떻게 동작할 것인가격리수준 -> 만약

JAXB -> Java Architectrue for XML BindingXML 정보를 오브젝트처럼 다룰 수 있음.XML 문서의 구조로 정의한 스키마를 이용해 매핑할 오브젝트의 클래스까지 자동으로 만들어주는 컴파일러 제공Unmarshalling -> XML문서를 읽어서

굳이 DI를 적용하지 않았더라고 자신이 사용하는 오브젝트의 클래스가 어떤 것인지 알지 못하게 만드는 것이 좋음인터페이스는 여러개 구현 가능하다(extends와 달리) -> 같은 타입으로 존재하지만 다른 구현을 가진 오브젝트를 만들 수 있음 (다형성) 자기참조 -> 스프

코드를 작성할때 DI를 의식하면서 설계하는게 좋음DI를 적용할때는 가능한 한 인터페이스를 사용하세 해야함HashMap -> 멀티쓰레드 환경에서 동시에 수정을 시도하거나 수정과 동시에 요청하는 경우 예상치 못한 결과가 발생할 수 있음.ConcurrentHashMap ->

스프링 3.1부터 XML을 전혀 사용하지 않고도 스프링 애플리케이션을 만들 수 있게 됨 @ImportResource("xml") -> 자바 클래스로 만들어진 DI 설정 정보에서 XML의 설정 정보를 가져옴<context:annotation-config> -> 에

DefaultListableBeanFactory (BeanFactory 상속) -> 대부분의 스프링 컨테이너는 이 클래스를 이용해 빈을 등록하고 관리함. @Autowired로 주입받을 수 있음. 컨테이너에 등록된 빈 이름, 정보 조회 가능중첩 멤버 클래스를 프로파일 설