본문 바로가기

토비의 스프링 정리

토비의 스프링 - 8.3 POJO 프로그래밍

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는 세 가지 조건을 만족해야 함
    1. 특정 규약(Contract)에 종속되지 않음
      • POJO는 꼭 필요한 API 외에는 종속되지 않아야 함
      • 특정 기술 및 규약에 따라 비즈니스 컴포넌트를 만드는 경우는 POJO가 아님
      • 특정 규약에 따르는 경우 대부분은 특정 클래스를 상속 받아야 함
      • 자바는 단일 상속을 원칙으로 하기 때문에, 특정 클래스를 강제로 상속 받아야 한다면 객체지향적인 설계 기법을 적용하기 어려워지는 문제가 발생하게 됨
      • 따라서, 특정 규약에 종속되지 않고 객체지향 설계의 자유로운 적용이 가능한 오브젝트여야만 POJO라고 불릴 수 있음
    2. 특정 환경에 종속되지 않음
      • 특정 환경에 종속적으로 동작하는 오브젝트 역시 POJO라 할 수 없음
      • EJB 3.0 에서 부터 특정 규약에 대한 종속성을 없앨 수 있었지만, 여전히 JNDI 서버라는 환경에 종속됨
      • 이렇게 특정 환경에 종속적이라면 POJO라 할 수 없음
    3. 객체지향 설계가 적용 돼야 함
      • 특정 기술과 환경에 종속적이지 않더라도 객체지향 설계가 적용되 POJO라 할 수 있음
      • POJO라 부르는 이유도 객체지향적인 자바 언어에 충실하기 위함임
      • 책임과 역할이 다른 코드를 한 클래스에 묶어 만능 클래스를 만들었어 특정 비즈니스 로직에 특정 기술과 환경이 나타나지 않더라도 객체지향적인 자바 오브젝트가 아니기 때문에 POJO라 할 수 없음
  • 즉, 비즈니스 로직에 단순 자바 오브젝트가 아닌 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 프레임워크를 어떻게 적용할지는 개발자의 부담임
  • 이를 위해 개발자는 객체지향 분석, 설계 및 리팩토링을 공부해야 함
  • 스프링을 사용한다 해서 이러한 부담을 줄일 수 있는 것은 아님
  • 단지 복잡한 엔터프라이즈 기술보다 객체지향적인 설계와 개발의 원리에 집중할 수 있도록 함