SpringFramework BeanFactory

스프링 프레임워크
 -> 설정사항이 많음
순서를 중요하게 기억!

프레임워크
 -> SW관점에서 어플리케이션의 전반적인 구조, 코드를 제공해주는 것
 -> 유지보수 과정에서 일관성이 망가짐

 장점 : 유지보수에 들어가는 비용이 절감
 유지보수 과정에서 아키텍처의 변형이 발생하지 않음 == 일관성 유지
 개발자는 비즈니스 로직만 구현하면됨 -> 개발 시간 감소
 개발자의 역량이 획일화



 스프링 프레임워크
  별도의 비용 XXX
다른 프레임워크와 연동이 용이

IoC와 AOP를 지원하는 경량(POJO)의 컨테이너 프레임워크

 장점 :
 - 경량(간단함)
   POJO를 사용

 - 컨테이너
   객체의 생성 및 객체 관리를 담당
   Servlet 컨테이너를 지금까지 사용해왔었음 -> 톰캣, 일반적으로 서번안에 포함되어 배포함
   => 스프링도 일종의 컨테이너! 객체간의 의존관계를 관리

 - IoC (제어의 역행 Inversion of Control)
   지금까지는 객체간의 결합을 개발자가 관리 -> 높은 결합도
   "낮은 결합도" 유지를 위해 컨테이너가 대신처리하게함!
의존관계를 변경해야 할때, 자바코드를 수정 ex) DAO의 메소드 인자를 VO로 사용
IoC가 적용되면 컨테이너가 객체를 생성하므로, 자바코드가 변경 XX

 - AOP(Aspect Oriented Programming 관점지향 프로그래밍) 방법론
   지금까지는 객체지향 프로그래밍(OOP)으로, 로직을 프로그래밍하고 있었음!
   주 업무 + 부가적인 업무
   핵심로직 계좌이체 입출금 이자계산
   부가적 로직 로직----------------------------
보안----------------------------
트랜잭션------------------------
  협업불리, 유지보수 어려움, 재사용 불리
  모든 로직을 핵심로직, 공통 로직으로 분리 == 응집도가 높아짐!


  사용자 -- web.xml --> 톰캣 <-> 디스패처, Controller -- 포워딩 --> View
  Controller 변경될때, 변경될 코드를 줄여나가는 것 == 결합도를 낮추는것 => 스프링을 사용하는 목표!
  설정파일로 조작할 수 있다! -> 의존성 주입(DI)

  [ IoC 컨테이너 ]
  서블릿은 자바로 구성된 클래스
  객체화 == 인스턴스화
  1. 서블릿 객체를 누가 만들어줬을까?
  2. doGet() 메소드를 어떻게 호출함?
  => Servlet Container
  개발자 : 서블릿 클래스 제작, web.xml 설정파일 작성
  1) web.xml 설정파일들을 loading(적재)
  2) Servlet Container 준비
  3) Client -- *.do GET --> 서블릿컨테이너
  4) 설정파일을 보고, 매핑된 서블릿 클래스를 찾아서 객체를 생성
  5) doGet() 메소드를 호출, 결과를 다시 전송(response)


 [ 낮은 결합도 ]
1. 높은 결합도의 코드
결합도 coupling -> 유지보수가 어려움
2. 결합도를 낮춰보자 -> 1
설계를 통한 상속관계 정의 (인터페이스)
형변환 -> 다형성(Polymorpism)
: 객체를 교체하는데에 용이
3. 결합도를 낮춰보자 -> 2
BeanFactory를 이용
: 디자인 패턴의 일종
클라이언트가 사용할 객체 생성 코드를 캡슐화
Person - Phone의 결합을 낮춰줌
-> 클라이언트는 필요한 객체를 BeanFactory에 요청
클라이언트가 사용할 객체를 생성하여 반환해주는것은 BeanFactory!