[Spring] SpringFramework

SpringFramework 등장배경

• EJB를 사용하면 애플리케이션 작성을 쉽게 할 수 있다.
• Low Level의 트랜잭션이나 상태관리, 멀티 쓰레딩, 리소스 풀링과 같은 복잡한 Low Level의 API 따위를 이해하지 못하더라도 아무 문제 없이 애플리케이션을 개발할 수 있다.
  
  
• EJB -> 현실에서의 반영은 어렵다.
  • 코드 수정 후 반영하는 과정 자체가 거창해 기능은 좋지만 복잡한 스펙으로 인한 개발의 효율성이 떨어짐
  • 어플리케이션을 테스트하기 위해서는 반드시 EJB서버가 필요하다.
    
    
• 웹사이트가 점점 커지면서 엔터프라이즈급의 서비스가 필요하게 됨
  • 세션빈에서 Transaction 관리가 용이함
  • 로긴, 분산처리, 보안 등
• 자바 진영에서는 EJB가 엔터프라이즈급 서비스로 각광을 받게 됨
  • EJB스펙에 정의된 인터페이스에 따라 코드를 작성하므로 기존에 작성된 POJO를 변경해야 함
  • 컨테이너에 배포를 해야 테스트가 가능해 개발속도가 저하됨
  • EJB는 RMI를 기반으로 하는 서버이므로 무거운 Container이다.
• EJB를 사용하지 않고 엔터프라이즈 어플리케이션을 개발하는 방법을 소개함
  • AOP나 DI같은 새로운 프로그래밍 방법론으로 가능
  • POJO로 전언적인 프로그래밍 모델이 가능해 짐

• 점차 POJO + 경량 프레임워크를 사용하기 시작
• POJO (Plain Old Java Object)
  • 특정 프레임워크나 기술에 의존적이지 않은 자바 객체
  • 특정 기술에 종속적이지 않기 때문에 생산성, 이식성 향상
  • Plain : component interface를 상속받지 않는 특징(특정 프레임워크에 종속되지 않는)
  • Old : EJB 이전의 java class를 의미
• 경량 프레임워크
  • EJB가 제공하는 서비스를 지원해 줄 수 있는 프레임워크 등장
  • Hibernate, JDO, iBatis(MyBatis), Spring

• POJO + Framework
  • EJB서버와 같은 거창한 컨테이너가 필요 없다.
  • 오픈소스 프레임워크라 사용이 무료
  • 각종 기업용 어플리케이션 개발에 필요한 상당히 많은 라이브러리가 지원
  • 스프링 프레임워크는 모든 플랫폼에서 사용이 가능하다.
  • 스프링은 웹 분야 뿐만이 아니라 어플리케이션 등 모든 분야에 적용이 가능한 다양한 라이브러리를 가지고 있다.

Spring Framework?

• 엔터프라이즈 급 애플리케이션을 만들기 위한 모든 기능을 종합적으로 제공하는 경량화된 솔루션이다.
• JEE(Java Enterprise Edition)가 제공하는 다수의 기능을 지원하고 있기 때문에, JEE를 대체하는 Framework로 자리잡고 있다.
• SpringFramework는 JEE가 제공하는 다양한 기능을 제공하는 것 뿐만 아니라, DI(Dependency Injection)나 AOP(Aspect Oriented Programmin)와 같은 기능도 지원한다.
  
  
• Spring Framework는 자바로 Enterprise Application을 만들 때 포괄적으로 사용하는 Programming 및 Configuration Model을 제공해 주는 Framework로 Application 수준의 인프라 스트럭쳐를 제공
• 즉, 개발자가 복잡하고 실수하기 쉬운 Low Level에 신경쓰지 않고 Business Logic 개발에 전념할 수 있도록 해준다.
• Enterprise System이란 서버에서 동작하며 기업의 업무를 처리해주는 System.

Spring Framework의 구조

• Spring 삼각형.

  • Enterprise Application 개발 시 복잡함을 해결하는 Spring의 핵심

  

• POJO(Plain Old Java Object)

  • 특정 환경이나 기술에 종속적이지 않은 객체지향 원리에 충실한 자바객체
  • 테스트하기 용이하며, 객체지향 설계를 자유롭게 적용할 수 있다.

• PSA(Portable Service Abstraction)

  • 환경과 세부기술의 변경과 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 설계 원칙

IoC(Inversion of Control, 제어의 역행)

• IoC/DI

• 객체지향 언어에서 Object간의 연결 관계를 런타임에 결정

• 객체 간의 관계가 느슨하게 연결됨(loose coupling)

• IoC의 구현 방법 중 하나가 DI(Dependency Injection)
  

• Dependency Lookup

  • 컨테이너가 lookup context를 통해서 필요한 Resource나 Object를 얻는 방식
  • JNDI 이외의 방법을 사용한다면 JNDI관련 코드를 오브젝트 내에서 일일이 변경해 주어야 함.
  • Lookup한 Object를 필요한 타입으로 Casting해 주어야 함
  • Naming Exception을 처리하기 위한 로직이 필요

• Dependency Injection

  • Object에 lookup 코드를 사용하지 않고 컨테이너가 직접 의존 구조를 Object에 설정할 수 있도록 지정해 주는 방식
  • Object가 컨테이너의 존재 여부를 알 필요가 없음
  • Lookup 관련된 코드들이 Object 내에서 사라짐
  • Setter Injection과 Constructor Inject

Container

• IoC Container
  • 오브젝트의 생성과 관계설정, 사용, 제거 등의 작업을 애플리케이션 코드 대신 독립된 컨테이너가 담당.
  • 컨테이너가 코드 대신 오브젝트에 대한 제어권을 갖고 있어 IoC라고 부름

• Spring DI Container

  • Spring DI Container가 관리하는 객체를 빈(Bean)이라 하고, 이 빈들의 생명주기(Life-Cycle)를 관리하는 의미로 빈팩토리(BeanFactory)라 한다.
  • Bean Factory에 여러 가지 컨테이너 기능을 추가하여 ApplicationContext라 한다.

  

IOC 개념

• 객체 제어 방식

  • 기존 : 필요한 위치에서 개발자가 필요한 객체 생성 로직 구현
  • IoC : 객체 생성을 Container에게 위임하여 처리

• IoC 사용에 따른 장점

  • 객체 간의 결합도를 떨어뜨릴 수 있음 (loose coupling).

• 객체간 결합도가 높으면?

  • 해당 클래스가 유지보수 될 때 그 클래스와 결합된 다른 클래스도 같이 유지보수 되어야 할 가능성이 높음

• 객체간 강한 결합

  • 클래스 호출 방식
  • 클래스내에 선언과 구현이 모두 되어 있기 때문에 다양한 형태로 변화가 불가능
    
  • MemberService 구현체와 AdminService 구현체를 HomeController에서 직접 생성하며 사용
  • MemberService 또는 AdminService가 교체되거나 내부 코드가 변경되면 HomeController까지 수정해야 할 가능성이 있음
    

• 객체 간의 강한 결합을 다형성을 통해 결합도를 낮춤

  • 인터페이스 호출 방식
  • 구현 클래스 교체가 용이하여 다양한 형태로 변화가능
  • 하지만 인터페이스 교체 시 호출 클래스도 수정해야 함

  

  • MemberService와 AdminService는 CommonService를 상속
  • HomeController에서 각 서비스를 이용 시 MemberService와 AdminService는 CommonService Type으로 사용 가능
    

• 객체 간의 강한 결합을 Factory를 통해 결합도를 낮춤

  • 팩토리 호출 방식
  • 팩토리 방식은 팩토리가 구현 클래스를 생성하므로 클래스를 호출
  • 인터페이스 변경 시 팩토리만 수정하면 됨. 호출 클래스에는 영향을 미치지 않음.
  • 하지만 클래스에 팩토리를 호출하는 소스가 들어가야함. 그것 자체가 팩토리에 의존함을 의미한다.
    
  • 각 Service를 생성하여 반환하는 Factory 사용
  • Service를 이용하는 쪽에서는 Interface만 알고 있으면 어떤 구현체가 어떻게 생성되는지에 대해서는 알 필요 없음
  • 이 Factory 패턴이 적용된 것이 Container의 기능이며 이 Container의 기능을 제공해 주고자 하는 것이 IoC모듈
    

• 객체 간의 강한 결합을 Assembler를 통해 결합도를 낮춤

  • IoC 호출 방식
  • 팩토리 패턴의 장점을 더하여 어떠한 것에도 의존하지 않은 형태가 됨
  • 실행시점에 클래스 간의 관계가 형성이 됨
    
  • 각 Service(객체)의 Life-Cycle을 관리하는 Assembler를 사용
  • Spring Container가 외부조립기(Assembler) 역할을 함.

  

Spring DI 용어 정리

• 빈(Bean)
  • 스프링이 IoC 방식으로 관리하는 오브젝트를 말한다.
  • 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 Bean이라고 부른다.
• 빈 팩토리(BeanFactory)
  • 스프링이 IoC를 담당하는 핵심 컨테이너
  • Bean을 등록, 생성, 조회, 반환하는 기능을 담당
  • 일반적으로 BeanFactory를 바로 사용하지 않고 이를 확장한 ApplicationContext를 이용한다.
• 애플리케이션 컨텍스트(ApplicationContext)
  • BeanFactory를 확장한 IoC 컨테이너
  • Bean을 등록하고 관리하는 기본적인 기능은 BeanFactory와 동일하다.
  • 스프링이 제공하는 각종 부가 서비스를 추가로 제공한다.
  • BeanFactory라고 부를 때는 주로 빈의 생성과 제어의 관점에서 이야기하는 것이고, 애플리케이션 컨텍스트라고 할 때는 스프링이 제공하는 애플리케이션 지원 기능을 모두 포함해서 이야기하는 것이라고 보면 된다.
• 설정정보/설정 메타정보(configuration metadata)
  • 스프링의 설정정보란 ApplicationContext 또는 BeanFactory가 IoC를 적용하기 위해 사용하는 메타정보를 말한다. 이는 구성정보 내지는 형상정보라는 의미이다.
  • 설정정보는 IoC 컨테이너에 의해 관리되는 Bean 객체를 생성할 때 사용됨
• 스프링 프레임워크
  • 스프링 프레임워크는 IoC 컨테이너, ApplicationContext를 포함해서 스프링이 제공하는 모든 기능을 통틀어 말할 때 주로 사용한다.