스프링이란 무엇인가? (토비의 스프링 vol.1 8장)

스프링의 정의

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

• 일반적인 라이브러리나 프레임워크
  • 특정 분야, 기술에 특화
• 애플리케이션 프레임워크
  • 특정 계층, 기술, 업무 분야에 국한되지 않고 애플리케이션 전 영역을 포괄하는 범용적인 프레임워크
• 스프링의 기원
  • 기술 서적의 예제코드
  • 자바 엔터프라이즈 개발의 전 계층의 기술, 애플리케이션 전 영역에 대한 효과적인 설계와 개발 기법을 다룸

• 단지 여러 계층의 기술을 모아둬서가 아닌 전 영역을 관통하는 일괄된 프로그래밍 모델과 기술을 바탕으로 각 분야의 특성에 맞는 필요를 채워줌

• 경량급 : 불필요하게 무겁지 않다
• EJB는 기술에 대한 과도한 욕심으로 인해 모든것을 부겁고 복잡하게 만들었다(불필요하게)

• 스프링 자체는 가볍지 않지만 EJB에 비해 가볍다

• 스프링은 기존 자바 엔터프라이즈 기술과 프레임워크와는 다르다
  • 엔터프라이즈 개발의 근본적인 문제점의 해결책을 제시한다
• EJB의 목표
  • 개발자가 실수하기 쉬운 로우레벨 기술을 신경쓰지않고 비즈니스 로직을 빠르고 효과적으로 구현

• 스프링은 개발자들이 비즈니스 로직에 집중하도록 해준다

• 스프링은 오픈소스 프로젝트 방식으로 개발되어왔다
  • 개발 과정은 공개되어 있지만 공식적인 개발은 SpringSource가 전담하고 있다
  • 오픈소스 프로젝트의 단점을 극복

스프링의 목적

2000년대 초반까지 자바 엔터프라이즈 프로젝트는 80% 이상이 정해진 기간과 예산을 맞추지 못하거나 중단되었다

• Enterprise 시스템
  • 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템
• Enterprise 개발의 복잡함
  • 많은 요청을 동시에 처리하기에 자원을 효율적으로 공유하고 분배하여 사용할 수 있어야 한다
  • 기업의 핵심 정보나 금융, 원자력, 항공, 국방 등의 시스템을 다루기도 하기에 뛰어난 보안과 안정성, 확장성을 요구함
  • 기술적인 고려사항이 많다
  • 엔터프라이즈 시스템이 관여하는 업무의 비율이 급격하게 커졌다
  • 상황에 따른 업무 프로세스의 변화
  • 비즈니스 로직의 복잡함과 기술적 복잡함이 얽혀 가중됨
• 실패한 EJB
  • 기술적인 복잡함을 로직에서 일부분. 분리하는 데는 성공
  • 특정 인터페이스 구현, 특정 클래스 상속, 서버에 종속적인 서비스를 통해서만 접근 가능 -> 더 큰 부담
  • 종속적인 코딩 요구로 자바의 장점(객체지향적 코딩)을 잃어버림
• 효과적인 스프링
  • 비침투적 방식의 코드 설계(기술 적용이 코드에 직접 반영되지 않음)와 구현의 제약이 없음

스프링의 해결 방법

• 기술적 복잡함
  • 기술에 대한 접근 방식이 일관성이 없고 특정 환경에 종속적이다
    • 환경이나 서버가 바뀌면 적용 기술과 코드도 달라져야한다
      • 서비스 추상화 기술을 통해 로우 레벨의 구현과 사용 부분을 분리
      • 환경과 세부 기술에 독립적인 인터페이스 제공
  • 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여 등장한다
    • 최대한 분리하고 의존적인 부분을 제거해도 근본적인 문제가 해결되지 않음
      • AOP를 통해 애플리케이션 로직을 담당하는 코드에 남아있는 기술 관련 코드를 깔끔하게 분리하여 별도의 모듈로 관리
• 비즈니스와 애플리케이션 로직의 복잡함
  • 비즈니스 로직의 오류는 엔터프라이즈 시스템을 사용하는 업무 자체에 타격을 준다
    • 객체지향 기법의 장점인 유연한 설계와 재사용성이 높다는 점을 활용한다
    • 스프링이 핵심 로직을 다르논 코드에 흔적을 남기지 않는다
• 객체지향과 DI
  • 과거 EJB는 자바 엔터프라이즈의 장점인 객체지향 설계를 살리지 못했다
  • DI를 통한 객체지향 설계
    • 서비스 추상화, 템플릿/콜백, AOP

POJO 프로그래밍

POJO(Plain Old Java Object) : 특정 기술에 종속되어 동작하는 것이 아닌 순수한 자바 객체

• POJO의 조건
  • 특정 규약에 종속되지 않는다
    • 특정 클래스 상속 시 객체지향적 설계 기법 적용이 어려움
    • 규약이 적용된 환경에 종속되어 이전이 힘듬
  • 특정 환경에 종속되지 않는다
    • 특정 환경이 의존 대상 검색 방식에 종속적이면 안된다
    • 순수한 애플리케이션 로직을 담고있는 오브젝트 코드가 특정 환경에 종속되면 안된다
    • 어느테이션을 사용하더라도 특정 기술과 환경에 종속적인 정보를 담고 있지 않으면 괜찮다

• 진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말하며 그런 POJO에 애플리케이션의 핵심 로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 한다

• POJO의 장점
  • 특정 기술과 환경에 종속되지 않는다
  • 자동화된 테스트에 유리하다
  • 객체지향적 설계를 그대로 코드에 반영할 수 있다
• POJO 프레임워크
  • POJO 프로그래밍이 가능하도록 기술적 기반을 제공하는 프레임워크
  • 대표적으로 스프링과 하이버네이트가 있다
  • 스프링은 엔터프라이즈 애플리케이션 전 영역에서 POJO 방식의 구현을 가능하게 하려는 목적으로 만들어짐
  • 기술영역에만 관여하고 비즈니스 로직에서는 모습을 감추면서 애플리케이션을 POJO로 쉽게 개발할수 있게 지원해준다

스프링의 기술

POJO 프로그래밍을 손쉽게 할 수 있도록 지원하는 세 가지 가능기술

• IoC/DI
  • 스프링의 핵심 개발 원칙
  • 유연한 확장이 가능하고 재사용이 가능하게 하기 위함
• DI의 활용방법
  • 핵심기능의 변경, 동적인 변경
  • 부가기능 추가
  • 인터페이스의 변경
  • 프록시 패턴 응용
  • 템플릿과 콜백 구현이 쉬움
  • 싱글톤과 오브젝트 스코프
  • 테스트
• AOP(Aspect Oriented Programming)
  • 객체지향 기술의 복잡해지는 요구사항과 기술적 난해함 해결의 한계
  • 객체지향 기술의 한계와 단점을 극복
  • POJO의 조건을 유지한채로 엔터프라이즈 서비스를 제공
  • 다이내믹 프록시(데코레이터 패턴), AspectJ를 이용하여 적용
• PSA(Portable Service Abstraction)
  • 환경의 변화와 상관없이 일관된 방식의 기술로 접근 환경을 제공