토비의 스프링 10. 스프링이란 무엇인가

스프링의 정의

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

어플리케이션 프레임워크

• 특정 계층이나 기술, 업무 분야에 국한되지 않고 (e.g. 웹 계층을 MVC 구조로 손쉽게 만들 수 있게 한다거나 관계형 DB 와 자바오브젝트를 매핑해주는 ORM 기술을 제공) 어플리케이션의 전 영역을 포괄하는 범용적인 프레임워크
• 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 어플리케이션 전 계층과 전 영역에 전략과 기능을 제공

경량급

• EJB와 같은 과도한 엔지니어링이 적용된 기술과 스프링을 대비시켜 설명하려고 사용하는 표현
• 스프링은 가장 단순한 서버환경인 tomcat에서도 완벽하게 동작하며 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 어플리케이션을 개발하기에 충분.

자바 엔터프라이즈 개발을 편하게 해주는

• 스프링은 어플리케이션 개발자들이 자신이 작성하는 어플리케이션의 로직에 더 많은 관심과 시간을 쏟게 해준다.
• 초기에 스프링의 기본 설정과 적용 기술만 잘 선택하고 준비해두면 이후로 어플리케이션 개발 중에는 스프링과 관련된 코드나 api에 대해 개발자가 거의 신경 쓸 일이 없다.

오픈소스

• 소스가 모두에게 공개되고 특별한 라이선스를 취득할 필요 없이 얼마든지 가져다 자유롭게 이용해도 된다
• 일반적인 오픈소스 프로젝트와 달리 스프링의 개발 과정은 공개되어 있지만 공식적인 개발은 제한된 인원의 개발자에 한정된다.
  • 오픈소스 개발 방식의 취약점인 지속적이고 안정적인 개발이 계속될지가 불확실하다는 단점 보완

스프링의 목적

• 경량급 프레임워크인 스프링을 활용해서 엔터프라이즈 어플리케이션 개발을 편하게하는 것

엔터프라이즈 개발의 복잡함

• 엔터프라이즈 개발
  • 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템
• 기술적인 제약조건
  • 서버 자원을 효율적으로 공유하고 분배하며 사용
  • 보안, 안정성, 확장성
  • 분산 트랜잭션의 지원
• 비즈니스 로직의 복잡함

복잡함을 해결하려는 도전

비침투적인 방식을 통한 해결책

• 기술적인 복잡함 - 어플리케이션 핵심 로직의 복잡함 분리
• 침투적인 기술
  • 어떤 기술을 적용했을 때 그 기술과 관련된 코드나 규약 등이 코드에 등장하는 경우.
  • e.g. EJB
• 비침투적인 기술
  • 기술의 적용 사실이 코드에 직접 반영되지 않음
  • e.g. 스프링

기술적 복잡함을 상대하는 전략

• 문제 : 기술에 대한 접근 방식이 일관성이 없고 특정 환경에 종속적
  • 해결 : 서비스 추상화
    • 로우 레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고 환경과 세부 기술에 독립적인 접근 인터페이스를 제공
• 문제 : 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장
  • 해결 : AOP
    • 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리

비즈니스와 어플리케이션 로직의 복잡함을 상대하는 전략

• 비즈니스 로직
  • 자주 변경되거나 수정되는 부분
• 객체지향 프로그래밍 기법과 언어가 주는 장점인 유연한 설계가 가능하고 재사용성이 높다는 점을 잘 활용하면 자주 바뀌고 조건이 까다로운 비즈니스 로직을 효과적으로 구현해낼 수 있음
• 비즈니스 로직의 복잡함을 상대하는 전략은 자바라는 객체지향 기술 그 자체이며 스프링은 단지 객체지향 언어의 장점을 제대로 살리지 못하게 방해했던 요소를 제거하도록 도와줄 뿐
• 객체지향과 DI
  • DI는 자연스럽게 객체지향적인 설계와 개발로 이끌어주는 좋은 동반자
  • DI를 의식하다보면 오브젝트를 설계할 때 자주 DI를 적용할 후보가 더 이상 없을까를 생각해보게 됨
• 현장의 업무를 잘 지원하고 유연하게 대응할 수 있는 뛰어난 애플리케이션을 만드는 것은 객체지향을 잘 활용해서 복잡한 문제를 풀어나갈 줄 아는 개발자의 능력에 달려 있다는 사실을 잊지 말아야 한다.
  • c.f. 토끼책, 오브젝트

POJO 프로그래밍

• 스프링 삼각형
  • POJO + (IoC/DI, AOP, PSA)
  • (IoC/DI, AOP, PSA) : 어플리케이션을 POJO 로 개발할 수 있게 해주는 가능기술

POJO

• plain old java object. 평범한 자바오브젝트
• 조건
  • 특정 규약에 종속되지 않는다.
    • 특정 규약을 따라 만들게 하는 경우는 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구
    • e.g. EJB2 는 비즈니스 컴포넌트가 EntityBean 클래스를 상속해야만 함
  • 특정 환경에 종속되지 않는다.
  • 객체지향적인 원리에 충실
• POJO 프로그래밍
  • POJO 에 어플리케이션 핵심 로직과 기능을 담아 설계하고 개발하는 방법

POJO 장점

• 특정 기술과 환경에 종속되지 않아서 코드가 깔끔하다
• 자동화된 테스트에 유리하다. 즉 유연한 방식으로 원하는 레벨에서 코드를 빠르고 명확하게 테스트 가능
• 객체지향적인 설계를 자유롭게 적용 가능

POJO 프레임워크

• 스프링은 엔터프라이즈 어플리케이션 개발의 모든 영역과 계층에서 POJO 방식의 구현이 가능하게 하려는 목적으로 만들어졌다.
• 스프링 자신은 기술 영역에서만 관여하고 비즈니스 로직을 담당하는 POJO에서는 모습을 감춘다.

토비님의 조언

• 객체지향적 POJO 프로그래밍을 어떻게 효과적으로 적용할지는 개발자에게 또 하나의 숙제이고 부담
• 객체지향 분석과 설계에 대한 지식을 습득하고 훈련
• 자바 언어와 JVM 플랫폼 그리고 JDK API 사용법 학습
• 디자인 패턴과 구현 패턴
• 리팩토링 기술

스프링의 기술

IoC/DI

활용 방법

• 핵심 기능의 변경
  • 의존 대상의 구현 바꾸기
• 핵심 기능의 동적인 변경
  • 어플리케이션이 동작하는 중간에 의존 대상을 다이내믹하게 변경
• 부가기능의 추가
  • 핵심기능은 그대로 둔 채로 부가기능을 추가
• 인터페이스의 변경
  • 사용하려고 하는 오브젝트가 가진 인터페이스가 클라이언트와 호환되지 않는 경우
  • 여러 종류의 인터페이스를 가졌지만 사실은 비슷한 기능을 담당하는 오브젝트를 바꿔가면서 사용하고 싶은 경우
  • 어댑터 패턴
• 프록시
• 템플릿과 콜백
  • 반복적으로 등장하지만 항상 고정적인 작업 흐름과 그 사이에서 자주 바뀌는 부분을 분리해서 템플릿과 콜백으로 만들고 이를 DI 원리를 응용해 적용하면 지저분하게 매번 만들어야 하는 코드를 간결하게 만들 수 있음
• 싱글톤과 오브젝트 스코프
  • 스프링의 DI 는 기본적으로 싱글톤으로 오브젝트를 만들어서 사용하게 함. 컨테이너가 알아서 싱글톤을 만들고 관리하기 때문에 클래스 자체는 싱글톤을 고려하지 않고 자유롭게 설계 가능
• 테스트
  • 스텁 또는 목 오브젝트 같은 테스트 대역 주입이 쉬움

AOP

• 객체지향 기술의 한계와 단점 극복을 도와주는 보조적인 프로그래밍 기술
• AOP 적용 기법
  • 다이내믹 프록시
  • 언어의 확장 이용
    • AspectJ
• AOP 적용 단계

1. 미리 준비된 AOP 이용
2. 전담팀을 통한 정책 AOP 적용
3. AOP의 자유로운 이용

PSA (포터블 서비스 추상화)

• 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해준다.