개념적으로 3가지 그림으로 나눌 수 있다.기획자들도 볼 수 있음이를 바탕으로 클래스 다이어그램을 만들어냄구체화해서 인터페이스와 구현체를 그림실제 서버를 실행하지 않고 클래스들만 분석해서 볼 수 있음동적으로 협력관계의 모습을 보여줌
AppConfig가 등장하면서 구성을 변경하기 위해 내부의 코드를 수정하지 않아도 된다.
제어의 역전, 말 그대로 프로그램 흐름의 제어가 역전되었다는 의미이다.
AppConfig 객체를 직접 생성 -> @Configuration 을 통해 스프링빈으로 등록시키고 AnnotationConfigApplicationContext 으로 컨텍스트를 불러와 빈을 가져옴빈 등록
xml로 설정정보를 주입한다면 컴파일을 따로 하지 않아도 된다는 장점이 있지만 불편해서 자바코드로 작성하는 추세이다.
스프링이 자바코드나 xml파일에서 설정정보를 가져와 빈을 만들 수 있는 이유는 추상화에 있다.
기본적인 싱글톤 코드싱글톤은 클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴이다.
appConfig 빈을 출력해보면 xxxCGLIB이라는 객체가 출력되는 것을 볼 수 있다.스프링이 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 클래스를 만들고 그 클래스를 스프링 빈으로 등록한다.
기존에 AppConfig 팩토리 빈 내에서 빈으로 등록할 클래스를 등록하고 직접 수동으로 의존관계 주입
스프링 애노테이션
좋은 설계란 제약이 있는 설계이다. 많은 getter, setter는 개발자를 혼란스럽게 할 뿐이다.
기존으로 주입할 빈(MemberRepository)이 존재하지 않는다면 에러를 뱉어낸다.
다음과 같이 DiscountPolicy를 상속받은 2개의 클래스가 빈으로 등록되어 있다고 가정한다.@Autowired의 기본 조회 로직은 타입에 근거하기 때문에 위와 같이 2개의 빈이 조회가 되면 에러를 발생시킨다.
기본적으로 자동주입을 이용자동주입을 사용해도 OCP, DIP 를 위반하지 않는다.
스프링이 뜰 때, 미리 서버와 디비는 서로 커넥션을 묶어놓고 커넥션 풀에 저장한다. 종료될 때도 안전하게 종료되어야 한다.
빈으로써 존재할 수 있는 범위를 의미한다.(default는 싱글톤, 빈 저장소에서 관리하는 범위)
동시에 여러 요청이 와도 한 요청에 같은 빈을, 다른 요청엔 다른 빈을 사용한다.