참조
- 토비의 스프링 vol.1 713p~752p
스프링이란?
자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크
애플리케이션 프레임워크
일반적인 라이브러리, 프레임워크는 로깅, ORM 등 특정 업무 분야나 한가지 기술에 특화된 목표를 가지고 만들어진다.
But 애플리케이션 프레임워크는 특정 계층이나, 기술, 업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크이다.
애플리케이션 프레임워크는 단지 여러계층의 다양한 기술을 한데 모아둔 것이 아니다.
만약 스프링이 MVC 프레임워크다, IoC/DI 프레임워크다 라고 한다면 일부 영역이나 기술에만 주목하는 것이다.
스프링의 일차적인 존재 목적은 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용 해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능을 제공해주는 것
→ 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임워크로 사용된다.
경량급
스프링이 가볍다?
→ 불필요하게 무겁지 않다는 의미.
→ EJB(엔터프라이즈 자바 빈)같은 과도한 엔지니어링이 적용된 기술의 복잡함에 반대되는 개념
- EJB는 개발 환경, 서버, 개발과 빌드 등등 모두 무겁고 복잡, 고가의 WAS가 필요 등등
- 반면에 스프링은 가장 단순한 서버환경인 Tomcat, Jetty에서도 동작한다. 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에 충분하다.
- 프레임워크와 서버환경에 의존적인 부분을 제거해주기 때문에 코드도 EJB보다 상대적으로 작고 단순하다.
자바 엔터프라이즈 개발을 편하게
편리한 개발이란?
→ 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션의 핵심인 비즈니스 로직을 빠르고 효과적으로 구현하는 것
스프링은 근본적인 부분에서 엔터프라이즈 개발의 복잡함을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시했다.
EJB의 목표도 이거였지만, EJB는 이 목표를 향한 과정에서 더 큰 복잡함을 가져왔다..
→ 스프링 프레임워크는 개발자들이 프레임워크 기술보다 애플리케이션의 로직에 더 많은 관심과 시간을 쏟게 해줌.
오픈소스
장점: 투명한 방식으로 다양한 참여. 매우 빠르고 유연한 개발이 가능.
단점: 지속적이고 안정적인 개발이 계속될지가 불확실함. 개발자 개개인에게 의존적임.
→ 오픈소스 개발이라는 방법을 선택해서 스프링의 개발과정은 공개되어있지만 공식적 개발은 SpringSource라는 기업이 전담함.
스프링의 목적
스프링의 목적은 복잡하고 어려운 엔터프라이즈 애플리케이션 개발을 편하게 하려는 것이다. 스프링이 어떻게 문제를 해결했는지 전략을 살펴보자.
엔터프라이즈 개발이 복잡한 이유
- 기술적인 제약조건과 요구사항이 늘어가기 때문
- 많은 사용자의 요청 동시에 처리하고 기업의 핵심정보나 중요한 시스템을 다룬다 → 서버 성능, 보안과 안정성, 확장성을 신경써야함. 비즈니스 로직 이외의 기술적 고려사항이 많음.
- 비즈니스 로직의 복잡함이 증가하기 때문
- 업무적인 변화의 속도가 빠르고 복잡해짐 → 기능 요구사항과 정책이 자주 바뀌고 자주 수정해줘야함.
- 1, 2의 복잡함이 한데 얽혀있기 때문
효과적인 해결책: 스프링
EJB는 기술 적용 시 그 기술과 관련된 코드나 규약이 코드에 등장 (침투적인 기술)
- 애플리케이션 핵심 로직에서 일부 기술적 코드를 분리하다가 오히려 EJB라는 환경과 스펙에 종속적인 코드로 만들게 강제함 → 자바언어가 원래 갖고있던 장점을 잃어버리게 함
스프링은 기술의 적용 사실이 코드에 직접 반영되지 않고, 기술의 적용에 따라 필요한 작업만 하고, 코드의 설계와 구현 방식을 제한하지 않음 (비침투적인 기술)
복잡함을 상대하는 스프링의 전략
- 기술적인 복잡함을 상대하는 전략
- 문제1 : 기술에 대한 접근방식이 일관성이 없고 특정 환경에 종속적 → 서비스 추상화
- ex: 트랜잭션 추상화, 데이터 액세스에 대한 일관된 예외변환 기능 등
- 로우레벨 기술구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부 기술에 독립적인 접근 인터페이스를 제공
- 문제2: 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장 → AOP
- ex: 트랜잭션, 보안적용, 로깅 등
- 기술관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리
- 문제1 : 기술에 대한 접근방식이 일관성이 없고 특정 환경에 종속적 → 서비스 추상화
- 비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략
- 자주 수정되고, 오류가 있으면 치명적.
- 과거: 비즈니스 로직의 상당 부분을 DB에 뒀음. → 가장 확장하기 힘들고 확장에 많은 비용이 드는 공유자원인 DB에 엄청난 부담 + 개발, 유지보수, 테스트가 전부 어렵다.
- 최근: 비즈니스로직은 애플리케이션 안에서 처리. → 확장하기 쉽고, 테스트하기도 쉬움. 객체지향 언어의 장점을 살려서 설계된 자바를 잘 활용하면 비즈니스 로직을 효과적으로 구현할 수 있다. 스프링은 비침투적인 기술이므로 이런 객체지향 프로그래밍을 방해했던 요소를 제거하도록 도와줄 뿐 관여하는건 없음.
- 기술과 비즈니스 로직의 복잡함을 해결하는데 공통으로 사용하는 도구: 객체지향과 DI
- 객체지향의 설계 기법을 잘 적용할 수 있는 구조를 만들기 위해 DI같은 유용한 기술을 편하게 적용하도록 도와주는 것이 기본 스프링의 전략.
- 서비스 추상화, 템플릿/콜백, AOP 등의 기법들 모두 DI를 바탕으로 하고 있음.
- DI는 특별한 기술이라기보단 유연하게 확장할 수 있는 객체지향 설계를 하다보면 적용되는 프로그래밍 기법이다. 그리고 더 객체지향적 설계와 개발로 이끌어준다.
- 스프링이 비침투적인 기술을 만드는 노력을 한 이유는 순수 비즈니스 로직을 담고 있는 코드에는 객체지향 설계에서 나온 도메인 모델을 쉽게 적용할 수 있기 때문.
- 결국 스프링의 기술과 전략은 객체지향이라는 자바 언어가 가진 강력한 도구를 극대화해서 사용할 수 있도록 돕는 것. 객체지향을 잘 활용하는건 개발자의 몫.
POJO
POJO란?
Plain Old Java Object
그냥 단순한 자바 오브젝트라는 뜻인데, 있어보이도록 만든 이름이다.
POJO의 조건
- 특정 규약에 종속되지 않는다.
- 자바 언어와 꼭 필요한 API외에는 종속되지 않아야 한다.
- 특정 환경에 종속되지 않는다.
- 특정 OS에서 제공하는 기능을 직접 호출하지 않고, WebLogic 서버에서만 사용가능한 API를 쓰지않은 코드
- 객체지향적 자바언어의 기본에 충실하다.
- 책임과 역할이 다른 코드를 다른 클래스로 분리, 다른 레이어 코드와 낮은 결합도
⇒ 진정한 POJO란 객체지향적 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트. 이런 POJO에 애플리케이션의 핵심로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있다.
POJO 프레임워크
스프링은 기술영역에만 관여하고, 비즈니스로직을 담당하는 POJO에서는 모습을 감춘다. 데이터 엑세스나 웹 UI 등 최소한의 방법으로 관여.
→ POJO 프레임워크로서 스프링은 자신을 직접 노출하지 않으면서 애플리케이션을 POJO로 쉽게 개발할 수 있게 지원해준다.
스프링의 기술
1. IoC/DI
DI를 하는 이유
- 유연한 확장을 가능하게하기 위해서
구체적인 DI의 활용방법
- 핵심 기능의 변경
- 핵심기능의 동적인 변경
- 부가기능의 추가
- 인터페이스의 변경
- 프록시
- 템플릿과 콜백
- 싱글톤과 오브젝트 스코프
- 테스트
2. AOP
보통 IoC/DI 기법으로 POJO프로그래밍을 하지만, 일부 서비스는 순수한 객체지향기법 만으로는 POJO의 조건을 유지한 채로 적용하기 힘듦 → 이런 문제를 해결하기 위해 AOP가 필요함
AOP의 적용 기법
- 스프링처럼 다이내믹 프록시 사용하기
- 데코레이터 패턴을 응용함. 만들기 쉽고 적용이 간편하지만, 부가기능을 부여할 수 있는 곳은 메서드 호출이 일어나는 지점으로 한정됨.
- 자바 언어의 함계를 넘어서는 언어의 확장을 이용하는 방법
- AspectJ사용, 별도의 AOP컴파일러 이용 등
AOP의 적용단계
- 어플리케이션에 AOP를 남발하다보면 혼란을 초래할 수 있다. 익숙하지 않다면 단계적으로
- 미리 준비된 AOP 이용하기
- 전담팀을 통한 정책 AOP 적용하기
- AOP의 자유로운 이용
3. PSA
- 트랜잭션은 AOP와 결합돼서 사용되기 때문에 직접적으로 서비스 추상화를 이용할 필요는 없음.
- OXM이나 JavaMail 등을 이용한다면 스프링이 정의한 추상 API를 이용해 코드를 작성하고, 구체적 기술과 설정은 xml파일로 지정한다.
- 스프링이 서비스 추상화 대상으로 포함시키지 않더라도 필요하면 직접 추상 레이어를 도입하고 일관성 있는 API를 정의해서 사용하라. 서비스 추상화에 필요한 기술은 DI뿐이다.
- 테스트가 어렵게 만들어진 API, 설정을 통해 주요 기능을 외부에서 제어하고 싶을 때도 서비스추상화를 이용해볼 수 있다.
