8.3.1 스프링의 핵심 : POJO
- 위 그림은 스프링으로 개발한 애플리케이션의 기본 구조임
- 스프링 애플리케이션은 POJO(Plain Old Java Object)를 이용해서 만든 애플리케이션 코드와 POJO가 어떻게 관계를 맺고 동작하는지를 정의해 놓은 설계정보로 구분됨
- DI의 기본 아이디어는 유연하게 확장 가능한 오브젝트르 만들어두고, 그 관계는 외부에서 다이내믹하게 설정해 준다는 것임
- 이런 DI의 개념은 애플리케이션 전반에 걸쳐 적용됨
- 스프링의 주요 기술은 Ioc/DI, AOP, PSA(Portable Service Abstraction, 서비스 추상화)는 애플리케이션을 POJO로 개발할 수 있게 하는 가능 기술(Enabling Technology)라 불림
8.3.2 POJO란 무엇인가?
- POJO라는 용어는 마틴 파울러가 컨퍼런스 발표를 준비하면서 만들었음
- 마틴 파울러는 자바의 단순한 오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하는 것이 바람직하다 생각했음
- 그럼에도 개발자들이 자바의 단순 오브젝트를 사용해 개발을 하지 않는 이유를, EJB와 같은 그럴싸한 이름이 없어서라고 생각했음
- 때문에, POJO 라는 이름을 만들어 냈음
- 간단한 자바 오브젝트를 사용하다는 것 보다, POJO 방식의 기술을 사용한다는 것이 더욱 있어보임
- 어쨌든, 자바의 단순한 오브젝트를 이용해 개발을 하는 방식이 POJO 방식임
8.3.3 POJO의 조건
- POJO는 세 가지 조건을 만족해야 함
- 특정 규약(Contract)에 종속되지 않음
- POJO는 꼭 필요한 API 외에는 종속되지 않아야 함
- 특정 기술 및 규약에 따라 비즈니스 컴포넌트를 만드는 경우는 POJO가 아님
- 특정 규약에 따르는 경우 대부분은 특정 클래스를 상속 받아야 함
- 자바는 단일 상속을 원칙으로 하기 때문에, 특정 클래스를 강제로 상속 받아야 한다면 객체지향적인 설계 기법을 적용하기 어려워지는 문제가 발생하게 됨
- 따라서, 특정 규약에 종속되지 않고 객체지향 설계의 자유로운 적용이 가능한 오브젝트여야만 POJO라고 불릴 수 있음
- 특정 환경에 종속되지 않음
- 특정 환경에 종속적으로 동작하는 오브젝트 역시 POJO라 할 수 없음
- EJB 3.0 에서 부터 특정 규약에 대한 종속성을 없앨 수 있었지만, 여전히 JNDI 서버라는 환경에 종속됨
- 이렇게 특정 환경에 종속적이라면 POJO라 할 수 없음
- 객체지향 설계가 적용 돼야 함
- 특정 기술과 환경에 종속적이지 않더라도 객체지향 설계가 적용되 POJO라 할 수 있음
- POJO라 부르는 이유도 객체지향적인 자바 언어에 충실하기 위함임
- 책임과 역할이 다른 코드를 한 클래스에 묶어 만능 클래스를 만들었어 특정 비즈니스 로직에 특정 기술과 환경이 나타나지 않더라도 객체지향적인 자바 오브젝트가 아니기 때문에 POJO라 할 수 없음
- 특정 규약(Contract)에 종속되지 않음
- 즉, 비즈니스 로직에 단순 자바 오브젝트가 아닌 HttpSession과 같은 특정 기술이나 특정 환경에 종속적이지 않고 객체지향 설계가 적용 돼야 POJO라 할 수 있음
- 애노테이션을 사용하는 경우, 부가적인 정보를 담고 있고 그 때문에 특정 환경에 종속적이지 않다면 POJO라 할 수 있음
- 하지만, 애노테이션이나 엘리먼트에 특정 기술과 환경에 종속적인 정보를 담고 있으면 POJO가 아님
8.3.4 POJO의 장점
- POJO의 조건인 특정 기술과 환경에 종속적이지 않는 코드는 깔끔한 코드가 될 수 있음
- 특정 기술 및 환경의 제약은 테스트 코드를 작성하기 매우 힘들기 때문에, POJO로 개발된 코드는 자동화된 테스트에 매우 유리함
- POJO의 코드는 매우 유연한 방식으로 원하는 레벨에서 코드를 빠르고 명확하게 테스트할 수 있음
- POJO는 객체지향적인 설계를 자유롭게 적용할 수 있음
- 재활용 가능한 설계 모델인 디자인 패턴 등은 POJO가 아니고 적용하기 힘듦
8.3.5 POJO 프레임워크
- 스프링은 POJO를 이용한 엔터프라이즈 애플리케이션 개발을 목적으로 하는 프레임워크임
- POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크를 POJO 프레임워크라 함
- 하이버네이트와 스프링이 대표적인 POJO 프레임워크임
- 하이버네이트는 DB 이용 기술에 POJO를 적용으로 하지만, 스프링은 애플리케이션 개발 전 영역과 계층에서 POJO 방식의 구현이 가능하게 하려는 목적으로 만들었음
- 스프링을 이용하면 POJO 프로그래밍 장점을 그대로 살리면서, 각종 서비스와 기술적 필요를 POJO 방식으로 만들어진 코드에 적용할 수 있음
- 위 그림은 스프링이 엔터프라이즈 시스템의 복잡함을 어떻게 다루는지 보여줌
- 스프링은 비즈니스와 기술의 복잡함을 분리해서 구성할 수 있게 함
- 기술영역은 비즈니스 로직을 담당하는 POJO에서 모습을 감춤
- 데이터 액세스 로직이나 웹 UI 로직을 다룰 때만 최소한으로 관여함
- POJO 프레임워크로서 스프링은 자신을 직접 노출하지 않으면서 애플리케이셔을 POJO로 쉽게 개발할 수 있도록 지원해 줌
- POJO 프레임워크를 어떻게 적용할지는 개발자의 부담임
- 이를 위해 개발자는 객체지향 분석, 설계 및 리팩토링을 공부해야 함
- 스프링을 사용한다 해서 이러한 부담을 줄일 수 있는 것은 아님
- 단지 복잡한 엔터프라이즈 기술보다 객체지향적인 설계와 개발의 원리에 집중할 수 있도록 함
'토비의 스프링 정리' 카테고리의 다른 글
토비의 스프링 - 8.5 8장 정리 (0) | 2022.10.26 |
---|---|
토비의 스프링 - 8.4 스프링의 기술 (0) | 2022.10.26 |
토비의 스프링 - 8.2 스프링의 목적 (0) | 2022.10.26 |
토비의 스프링 - 8.1 스프링의 정의 (0) | 2022.10.26 |
토비의 스프링 - 7.7 7장 정리 (0) | 2022.10.26 |