Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr Chapter 8. 스프링이란 무엇인가? Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr.

Presentation on theme: "Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr Chapter 8. 스프링이란 무엇인가? Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr."— Presentation transcript:

1 Sep. 2014 Youn-Hee Han http://link.koreatech.ac.kr
Chapter 8. 스프링이란 무엇인가? Sep. 2014 Youn-Hee Han

2 8.1 스프링의 정의

3 8.1 스프링의 정의 일반적인 스프링의 정의 정의 내 단어 1 - 애플리케이션 프레임워크
자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크 스프링의 기원 로드 존슨(Rod Jhonson)이라는 유명 J2EE 개발자가 출간한 “Expert One-on-One J2EE Design and Development”이라는 제목의 책에 소개된 예제 샘플 정의 내 단어 1 - 애플리케이션 프레임워크 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는데 일차적인 목표 애플리케이션 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심 기술 제공

4 8.1 스프링의 정의 정의 내 단어 2 – 경량급 불필요하게 무겁지 않다는 뜻
예전의 무거운 EJB (Enterprise JavaBeans)의 과도한 엔지니어링 기술에 비해 가벼운 스프링을 설명하는 단어 코드는 더 단순하고 개발과정은 더 편리해짐 EJB에서 불편했던 고급 기능을 세련된 방식으로 적용가능 스프링으로 만들어진 코드는 EJB기반으로 만들어진 코드와 기술수준은 비슷하면서도 생산성과 품질면에서는 더 유리함

5 8.1 스프링의 정의 정의 내 단어 3 – 자바 앤터프라이즈 개발을 편하게
근본적으로 앤터프라이즈 개발의 복잡함을 제거하고 편하게 개발할 수 있는 해결책 제공 EJB 1.0 스펙에서 제시된 EJB 목표와 비슷 스프링은 위와 같은 EJB가 궁극적으로 이루려고 했던 목적을 제대로 실현해주는 프레임워크

6 8.1 스프링의 정의 정의 내 단어 4 – 오픈소스 온라인 커뮤니티 공식적인 개발자 및 업체
소스가 모두에게 공개되고 특별한 라이선스를 취득할 필요없이 자유롭게 이용가능 스프링에 적용된 오픈소스 라이선스 Apache License Ver. 2.0 상업적인 제품에 포함하거나 비공개 프로젝트에 자유롭게 이용가능 다만 스프링을 이용하고 있으며, 원 저작자에 대한 정보는 포함해야 하는 의무사항 존재 필요하다면 기존 소스를 수정하여 사용가능하며 수정된 내용에 대한 공개 의무는 없음 온라인 커뮤니티 의견 공유, 버그 신고, 기능 추가 요청, 피드백 등 공식적인 개발자 및 업체 초기부터 공식적인 개발자 그룹 존재해왔음 SpringSource 업체에서 코드 개발 주관해옴 2009년 SpringSource는 VMWare 업체에 합병됨 더욱 안정된 환경과 조직에서 스프링 소스를 개발하고 있음

7 8.2 스프링의 목적

8 8.2.1 앤터프라이즈 개발의 복잡함 앤터프라이즈 개발의 복잡함

9 8.2.1 앤터프라이즈 개발의 복잡함 앤터프라이즈 시스템이 복잡한 이유 2. 비즈니스 로직의 복잡함 증가
1. 엔터프라이즈 IT에 대한 기술적인 제약조건과 요구사항 증가 서버의 자원을 효율적으로 공유 및 배분해야 하는 요구 보안, 안정성, 확장성 요구 웹과의 연동 요구 위와 같은 요구사항은 계속하여 증가하고 있음 새로운 기술의 지속적인 등장 2. 비즈니스 로직의 복잡함 증가 여러 조직의 업무를 처리하기 위한 핵심 비즈니스 로직 복잡 기존 전통적인 기업 업무 처리에 대한 엔터프라이즈 시스템 의존도가 지속적으로 높아지고 있음 매우 많은 예외사항 비즈니스 로직의 잦은 변경

10 8.2.1 앤터프라이즈 개발의 복잡함 앤터프라이즈 시스템이 복잡한 이유
3. 엔터프라이즈 IT 기술과 비즈니스 로직의 복잡함이 함께 얽혀 있음 개발자가 동시에 두 가지를 모두 신경 써서 개발해야 하는 과도한 부담

11 8.2.2 복잡함을 해결하려는 도전 제거될 수 없는 근본적인 복잡함
엔터프라이즈 개발은 현실적으로 매우 복잡함 기술적인 복잡함을 해결하고자 보안을 취약하게 할 수 없음 근본적으로 앤터프라이즈 개발에 나타나는 복잡함의 원인은 제거 대상이 아니라 그것을 효과적으로 상대할 수 있는 전략과 기법이 중요 비즈니스 로직의 복잡함 기술적인 복잡함 위 두 가지 복잡함을 분리하여 처리하는 것이 효율을 높이는 첫걸음 실패한 해결책: EJB (Enterprise Java Beans) EJB의 실패 원인 EJB의 침투적 (Invasive)인 성격 반드시 코드는 EJB라는 기술과 관련된 코드, 규약, 환경 및 스펙에 종속됨 기술적인 복잡함을 덜어주려다가 오리혀 더 큰 복잡함을 추가하는 실수를 범함

12 8.2.2 복잡함을 해결하려는 도전 효과적인 해결책: 스프링 비침투적인 방식 활용
기술의 적용 사실이 코드에 직접적으로 반영되는 것을 최소화함 스프링 기술의 적용에 따라 필요한 작업은 요구되지만, 애플리케이션 코드 이곳 저곳에 불쑥 등장하거나 코드의 설계와 구현 방식을 제한하지 않는다. 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리 가능 성격이 다른 복잡함이 서로서로 분리가 잘 되어짐 개발의 효율성을 극대화하는 방향으로 발전됨

13 8.2.3 복잡함을 상대하는 스프링의 전략 기술적 복잡함을 상대하는 전략
문제 1. 기술에 대한 접근 방식에 일관성이 없고 개발 코드가 특정 환경에 종속됨 변화하는 동적 환경 서버의 교체, API 사용 방법의 변화 일관성이 없는 기술의 난립 호환이 안되는 표준, 오픈 소스의 난립 등 문제 1에 대한 해결 전략 인터페이스 활용을 통한 서비스 추상화 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리, 이용하는 측에서는 인터페이스를 통해 접근 불필요한 예외를 잡아야 하거나 throw선언을 최대한 방지 템플리/콜백 패턴을 통해 반복적인 작업 코드 제거 개발자는 핵심 로직에 집중 가능

14 8.2.3 복잡함을 상대하는 스프링의 전략 기술적 복잡함을 상대하는 전략
문제 2. 기술적 처리 담당 코드가 비즈니스 로직 처리 코드에 섞여서 등장 비즈니스 로직 전후의 트랜잭션 경계설정 코드 등장 비즈니스 로직에 보안 적용 코드 등장 계층 사이에 주고 받는 데이터 변환 문제 문제 2에 대한 해결 전략 AOP 비즈니스 로직 담당 코드로 부터 기술 관련 코드를 완벽하게 분리할 수 있는 기술 코드의 복잡함이 비즈니스 로직의 복잡함 이상으로 불필요하게 증대됨을 방지해줌

15 8.2.3 복잡함을 상대하는 스프링의 전략 비즈니스 로직의 복잡함을 상대하는 전략 복잡함의 정도 차이
비즈니스 로직 ≫ 기술적 로직 비즈니스 로직이 훨씬 복잡하고 더욱더 복잡해지고 있음 업무 정책과 흐름의 복잡도 증가 치명적 손실/위험 정도의 차이 비즈니스 로직 핵심 코드에 오류가 있다면 시스템을 사용하는 업무 자체에 매우 큰 지장을 주거나 치명적 손실 발생 예. 1) 증권사 사이트에서 주식거래 완료를 했는데도 체결이 안되어 있음. 2) 은행 계좌 잔고가 이유도 없이 줄어듬  회사 문 닫을 수도 있음

16 8.2.3 복잡함을 상대하는 스프링의 전략 비즈니스 로직의 복잡함을 상대하는 전략 DB에서 비즈니스 로직 처리 방법의 변화
이전 방식 비즈니스 로직이 잘 반영되도록 SQL을 잘 작성함 저장 프로시저 (Stored Procedure)에서 핵심 로직 처리 최근에 깨달은 교훈 DB에 비즈니스 로직을 두는 것은 유지보수가 매우 불편함 테스트가 매우 힘듦 최근 추세 DB는 단지 영구적인 저장과 복잡한 조건을 가진 검색 정도의 기능으로 한정 데이터를 가공하고 분석하고 처리하는 로직은 가능하면 객체 지향 애플리케이션 서버에 둠 비즈니스 로직의 복잡함을 상대하는 전략은 자바의 객체지향 기술 그 자체 스프링은 자바의 객체 지향 방식을 최대한 활용하도록 은밀히 도와줌

17 8.2.3 복잡함을 상대하는 스프링의 전략 핵심 도구: 객체지향과 DI 스프링의 모토 DI를 기본으로 둔 기술 DI의 역할
“기본으로 돌아가자” 기본적인 객체지향에 충실한 설계가 가능하도록 도와줌 DI를 기본으로 둔 기술 서비스 추상화, 템플릿/콜백, AOP 등 스프링의 중요 기술 인터페이스로 분리하고 구체적인 클래스의 객체는 동적으로 의존관계를 만듦 DI의 역할 자연스럽게 객체지향적인 설계와 개발로 이끌어줌 DI를 의식하면서 설계할 때 고려하는 것들 DI를 적용할 후보가 더 없나? 변경되는 것은 어떤 것일까? 성격이 다른 기능은 무엇일까?

18 8.2.3 복잡함을 상대하는 스프링의 전략 핵심 도구: 객체지향과 DI 객체 지향 설계의 중요성
객체 지향 설계 기법 상속, 다형성, 위임등을 포함한 다양한 디자인 패턴 및 설계 기법 스프링은 객체 지향 설계 및 코딩을 단지 거들 뿐임 복잡한 엔터프라즈 시스템 개발을 잘 하는 방법 객체 지향 설계 기법에 익숙해져야 함 스프링만 잘 공부하는 것으로는 부족함

19 8.3 POJO 프로그래밍

20 8.3.1 스프링의 핵심: POJO “스프링의 정수(Essence)는 앤터프라이즈 서비스 기능을 POJO에 제공하는 것“
트랜잭션 및 보안 기능 등 위 말을 뒤집어 생각하면 앤터프라이즈 서비스 기능과 POJO라는 비즈니스 로직을 담은 코드가 잘 분리했다는 것을 의미 스프링의 가장 강력한 특징 및 목표 분리되었지만 반드시 필요한 앤터프라이즈 서비스 기술을 POJO 방식으로 개발된 비즈니스 핵심 로직을 담은 코드에 제공함

21 8.3.1 스프링의 핵심: POJO 스프링의 핵심 개념을 설명하기 위해 만든 유명한 그림
애플리케이션을 POJO로 개발할 수 있도록 하는 가능기술 (Enabling Technology) IoC/DI AOP PSA (Portable Service Abstraction)

22 8.3.2 POJO란 무엇인가? POJO (Plain Old Java Objects)의 단어 유래 위 발표 이후…
Martin Fowler가 2000년도에 컨퍼런스 발표를 위해 만든 용어 발표 내용의 핵심 EJB는 너무 복잡하고 제한이 많은 기술임을 설명 그럼에도, 많은 개발자가 자바의 단순한 객체만을 사용하는 것을 꺼리는 이유를 생각함 그 이유 중 하나가 EJB와 같은 멋진 이름이 없었기 때문이라고 생각 “POJO 방식의 기술을 사용합니다.” ≫ “간단한 자바 객체를 사용합니다.“ 위 발표 이후… POJO를 지원하는 것을 장점으로 내세우는 많은 프레임워크와 기술이 쏟아져 나옴 심지어 EJB 3.0 조차 기존의 문제점을 반성하고 POJO를 적극 도입하기 시작함

23 8.3.3 POJO의 조건 POJO의 조건 특정 규약(Contract)에 종속되지 않는다. 특정 환경에 종속되지 않는다.
개발자는 자유로운 객체지향 설계에 방해를 받으면 안됨 반대 예 스트럿츠 1에서 빈은 특정 클래스를 상속해서 만들어야 함 특정 환경에 종속되지 않는다. EJB 3에서 빈은 반드시 JNDI 기술을 통해서 가져와야 함 WebLogic 서버에서만 사용가능한 API를 사용하는 빈 웹 환경에 의존적인 빈 비즈니스 로직 처리 빈이 HttpServletRequest 객체를 직접적으로 이용하는 경우 애노테이션 사용하는 빈 해당 애노테이션이 특정 환경에만 적용된다면 부적합 재사용성이 높아야 한다. 책임과 역할이 다른 코드를 모두 가지고 있는 덩치 큰 빈

24 8.3.4 POJO의 장점 POJO의 장점 로드 존슨 (스프링 창시자) 깔끔한 코드 생산 자동화 테스트에 유리
객체지향 설계를 자유롭게 적용가능 로드 존슨 (스프링 창시자) “자바 언어의 객체지향적인 설계와 구현 방식이야 말로 그 어떤 새로운 기술, 환경, 도구보다 더 실제 프로젝트를 성공시키는 데 중요한 요소”

25 8.3.5 POJO 프레임워크 POJO 프레임워크 POJO를 이용한 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크
개발자들이 객체지향적인 설계와 원리에 집중할 수 있도록 도와줌 하이버네이트: DB 이용 기술에 POJO를 적용함

26 8.4 스프링 기술

27 8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
스프링의 핵심 기본 기술, 스프링의 핵심 개발 원칙 두 개의 객체를 분리해서 개발 그 두 개의 객체 사이에 인터페이스를 두고 느슨하게 연결 실제 사용할 대상은 DI를 통해 외부에서 지정받음 다른 두 가지 기본 기술인 AOP와 PSA도 IoC/DI에 기반을 둠 3대 기술은 아니지만 템플리/콜백도 IoC/DI에 기반을 둠 IoC/DI 사용 이유? “개방 폐쇄 원칙 (OCP)를 지키며 어플리케이션의 유연한 확장을 위하여…“ 폐쇄 관점에서 볼 때 재사용성도 높아짐

28 8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
AB 의존관계 고려 B관점에서는 유연한 확장이 자유로움 전략 패턴 사용 B의 구현 방식을 필요에 따라 B1, B2, B3로 변경 A관점에서는 자유롭게 확장된 B를 자유롭게 재사용할 수 있음 즉, 의존 대상이 B1, B2, B3로 변경되어도 A는 그대로 사용 활용 예 사용자 관리 서비스를 구현한 B1에서 사용자 등급을 변경하는 정책이 변경되면 새롭게 B2를 구현하고 DI를 통해서 A에게 새로운 사용자 관리 서비스를 넘겨줌

29 8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
데코레이션 패턴 적용이 쉬워짐 활용 예 트랜잭션 기능 부여 클라이언트와 타겟 객체 코드에는 전혀 영향 없음 IoC/DI의 역할 3: 인터페이스의 변경 원래: AB 인터페이스 원하는 변경: A  C 객체 C는 B 인터페이스를 구현하지 않음 방법: 어댑터 객체 D 생성 B 인터페이스를 구현하면서 내부적으로 C 객체를 호출하는 객체 결과: A  B (D 객체)  C

30 8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
지연된 로딩 (Lazy Loading) 적용 Remoting (원격 객체 호출) 구현에 활용 IoC/DI의 역할 5: 템플릿과 콜백 템플릿 반복적으로 등장하지만 항상 고정적인 작업 흐름을 담당 콜백 자주 변경되는 부분 템플릿 호출시에 콜백 객체를 DI 하여 사용함 스프링은 20여가지의 전형적인 템플릿/콜백 적용 기술 제공 전형적인 DI가 사용되지 않는 경우도 많음

31 8.4.1 제어의 역전(IoC)/의존관계 주입(DI)
빈 객체의 생성, 관계설정, 이용, 소멸 담당 객체의 스코프 제어 기본 객체 스코프을 싱글톤으로 보장해줌 즉, 프로그래머가 특별하게 신경쓰지 않고 객체를 생성하여도 엔터프라이즈 용으로 활용 가능함 싱글톤이 아닌 다른 스코프가 필요해도 쉽게 구성가능 Prototype 스코프 Request 스코프 Session 스코프 IoC/DI의 역할 7: 테스트 목 오브젝트 생성 및 주입 수정자 메소드를 직접 호출하는 수동 DI를 사용가능

32 8.4.2 애스팩트 지향 프로그래밍 (AOP) AOP 특성 AOP 적용 기법 2. AspejctJ 사용
OOP와 AOP는 서로 배타적인 것이 아님 AOP는 OOP의 기술적인 한계를 극복해주는 보조적인 프로그래밍 기술 OOP를 더욱 OOP 답게 코딩 가능하게 해 줌 POJO 만으로 앤터프라이즈급 어플리케이션 개발의 핵심 역할 수행 AOP 적용 기법 1. 다이내믹 프록시 사용 스프링에서 주로 활용하는 방식 메소드 호출에 대해 부가기능 추가 앤터프라이급 개발에서 필요한 대부분의 AOP는 다이내믹 프록시 방법으로 충분 2. AspejctJ 사용 고급 AOP 적용시 활용

33 8.4.2 애스팩트 지향 프로그래밍 (AOP) AOP 적용 단계 1단계: 미리 준비된 AOP 이용
@Transactional 애노테이션 사용 도메인 객체에 DI를 자동 적용하는 기술 @Configurable 애노테이션 사용 AspectJ 사용 필요 2단계: 전담팀을 통한 정책 AOP 적용 예 1. 전체 객체 및 서비스에 대한 보안, 로깅, 데이터 추적 (트레이싱), 실시간 성능 모니터링 같은 정책적 기능 구현에 적용 예 2. 개발 가이드라인이나 표준을 따라서 코딩이 되고 있는지를 검증하는 작업 JSP 뷰에서 DAO의 직접 이용등을 검출할 수 있음 3단계: AOP의 자유로운 이용 개발자 스스로가 AOP를 활용하여 특정 기능을 AOP 기능으로 분리 주의: 다른 팀이나 개발자가 만드는 곳에 몰래 적용하면 안됨

34 8.4.3 포터블 서비스 추상화 (PSA) PSA (Portable Service Abstraction)
환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근하게 해주는 기술 스프링은 엔터프라이즈 개발에 사용되는 다양한 기술에 대해 PSA를 제공함 PlatformTransactionManager: 트랜잭션 서비스 추상화 인터페이스 org.springframework.mail.javamail 패키지 OXM (Object-XML Mapping) 기능 PSA를 실현하기 위해 필요한 기술  IoC/DI