POJO란?

POJO (Plain Old Java Object)

 

POJO (Plain Old Java Object) 란 번역하면 '평범한 구식 자바 객체'이다. 도대체 평범하고 구식인 자바 오프젝트가 뭐가 다르고 특별해서 POJO라고 부르는 것일까? 그럼 평범하지 않은 최신의 자바 오브젝트는 무엇인가?

 

POJO를 이해하려면 POJO라는 단어가 만들어진 역사적 배경을 살펴볼 필요가 있다. POJO는 마틴 파울러가 2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 만들어낸 말이다. 마틴 파울러는 EJB(Enterprise JavaBean)보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이 있는데 왜 사람들이 EJB가 아닌 '평범한 자바 오브젝트'를 사용하기를 꺼려하는지에 대해 의문을 가졌다. 그리고 그는 단순한 오브젝트에는 EJB와 같은 그럴듯한 이름이 없어서 그 사용을 주저하는 것이라고 결론을 내렸고, POJO라는 용어를 만들었다.

 

 

EJB와 엔터프라이즈 서비스

 

 자바에서 EJB 기술의 등장은 필연적인 것이었다. 기업의 IT 시스템은 점점 그 중요성이 증대되고 그에 따라 점점 기술이 요구되었으며 자바의 기초적인 JDK만으로는 그것을 충족시킬 수 없었다. 서버 기반의 자바 기술인 J2EE(Java2 Enterprise Edition)가 등장했지만 Servlet, JSP 레벨의 최소한의 서버 프로그래밍 인터페이스만 가지고는 복잡한 엔터프라이즈 애플리케이션을 제작하는데 부담이 적지 않았다.

 

 기업업무처리의 IT시스템에 대한 의존도가 높아지면서 시스템이 다뤄야 하는 비즈니스 로직 자체가 점차 복잡해졌다. 애플리케이션 로직의 복잡도와 상세 기술의 복잡함을 개발자들이 한 번에 다룬다는 것은 쉬운일이 아니었다. 예를 들어, 한 개발자가 보험업무와 관련된 계산 로직을 자바로 어떻게 구현해야 하는지에 집중하면서 동시에 시스템 레벨에서 멀티 DB로 확장 가능한 트랙잭션 처리와 보안 기능을 멀티스레드에 세이프하게 만드는 것에 신경써야한다면 여간 부담되는게 아닐 것이다.

 많은 사용자의 처리요구를 빠르게 안정적이면서 확장 가능한 형태로 유지하기위해 필요한 로우레벨의 기술적인(트랜젝션 처리, 상태관리, 멀티쓰레딩, 리소스풀링, 보안등) 처리가 요구되었다.

 

EJB는 이런 문제를 다루기 위해 등장했다. EJB 1.0의 스펙이 제시한 EJB의 비전은 'EJB는 애플리케이션 개발을 쉽게 만들어준다. 애플리케이션 개발자는 로우레벨의 기술들에 관심을 가질 필요도 없다.' 였다. 애플리케이션 개발자들은 다뤄야하는 해당 도메인과 비즈니스 로직에만 집중하면 된다는 것이다. 게다가 EJB는 독립적으로 개발한 컴포넌트들을 서버에 자유롭게 배포하고 서로 연동해 사용하게하는 컴포넌트 기반의 개발 모델을 제시할 뿐더러, 여러 대의 서버에 분산되어있는 모듈간의 리모팅 처리도 개발자들이 거의 신경쓰지 않고 개발 할 수 있게 했다. 더 나아가 벤더별로 제각각 발전시켜 혼란에 빠지기 쉬운 자바의 서버 기술을 일관성있게 구현할 수 있도록 지원하므로 특정 서버에 종속되지 않고 서버간의 이동성을 보장해준다고 약속했다.

 

 그러나, EJB는 불필요할만큼 과도한 엔지니어링으로 실패한 대표적인 케이스였다.

EJB에서는 현실에서 1% 미만의 애플리케이션에서만 필요한 멀티 DB를 분산 트랜잭션을 위해 나머지 99%의 애플리케이션에서도 무거운 JTA기반의 글로벌 트랙잰션 관리 기능을 사용해야 했다. EJB의 혜택을 얻기 위해 모든 기능이 다 필요하지도 않은 고가의 WAS를 구입해야했고, 고급 IDE(Intergrated Development Environment)의 도움없이는 손쉽게 다룰 수 없는 복잡한 설정 파일 속에서 허우적대야 했다. EJB 컴포넌트는 컨테이너 밖에서는 정상적으로 동작할 수 없으므로 개발자들은 끝도없이 반복되는 수정-빌드-배포-테스트의 지루한 과정으로 많은 시간을 낭비해야했다. 가장 최악의 문제점은 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 포기해야했다는 것이다. EJB 빈은 상속과 다형성등의 혜택을 제대로 누릴 수 없었다.

 

 그럼에도 EJB가 계속 사용되었던 이유는, 엔터프라이즈 애플리케이션에서 반드시 필요로하는 주요한 엔터프라이즈 서비스들을 애플리케이션 코드와 분리해서 독립적인 서비스로 사용할 수 있게 만들어줬다는 점이다. 비록 불완전하고 불필요한 복잠도가 남아있긴 했지만 선언적인 트랜잭션 관리나 역할 기반의 보안 기능들을 제공했다. 한편으로는 '개발자들이 로우레벨의 기술적인 문제에 신경쓰지 않고 비즈니스 로직에 충실히 개발하게 함으로써 애플리케이션 개발을 손쉽게 만들어 준다'는 처음 약속을 어느 정도 지켰다고 볼 수 있었다. 하지만 EJB 문제는 앞서 지적한 것처럼 한편으로는 애플리케이션 개발의 복잡도를 제거하면서 다른 한편으로는 더 많은 문제와 복잡성을 가지고 왔다는 것이다.

 

 결국 EJB는 형편없는 생산성과 느린 성능, 불필요한 기술적인 복잡도등으로 자반의 엔터프라이즈 개발에 대한 불신을 가중시켰다. 마틴 파울러는 EJB와 같은 잘못 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바 언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO 방식으로 돌아서야 한다고 지적했다. POJO 방식의 개발은 EJB가 잃어버린 소중한 가치인 객체지향적인 설계와 자동화된 테스트의 편의성, 개발생산성 등을 회복시켜 줄 수 있는 길이기 때문이다.

 

결국 POJO를 정리하자면,

• 특정 규약(contract)에 종속되지 않는다. (Java 언어와 꼭 필요한 API 외에 종속되지 않는다.)
• 특정 환경에 종속되지 않는다.
• 객체지향원리에 충실해야 한다.

POJO를 사용하는 이유

• 코드의 간결함 (비즈니스 로직과 특정 환경/low 레벨 종속적인 코드를 분리하므로 단순하다.)
• 자동화 테스트에 유리 (환경 종속적인 코드는 자동화 테스트가 어렵지만, POJO는 테스트가 매우 유연하다.
• 객체지향적 설계의 자유로운 사용

 

 앞에서 강조한것처럼 EJB를 사용하지 말고 POJO를 쓰자는 것이 EJB 이전의 방식으로 돌아가는 것을 의미한다면 또 다른 문제가 발생할 수밖에 없다. 여전히 복잡한 로우레벨의 API를 이용해 코드를 작성해야하고, 많은 기술적인 문제를 애플리케이션 코드에 그대로 노출시켜 개발해야 한다면 기껏 POJO로의 복귀 덕분에 얻은 많은 장점을 놓칠 수 밖에 없다. 그래서 등장한 것이 바로 POJO 기반의 프레임워크이다.

 

 

POJO 프레임워크 

 

 POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주는 프레임워크, 나아가 기존의 EJB에서보다 훨씬 더 세련되고 나은 방법을 제공한다.

(많은 POJO 프레임워크가 있지만 그 중에서 가장 대표적인 것을 꼽으라면 하이버네이트와 스프링을 들 수 있다.)

 

 

 

스프링 프레임워크

 

스프링 : POJO 프레임워크 중 하나이며, 자바 애플리케이션 개발을 위한 포괄적인 인트라 스트럭처를 제공하는 자바 플랫폼이다. 

스프링을 사용하면 POJO로 어플리케이션을 만들고 엔터프라이즈 서비스를 비침투적으로 POJO에 적용할 수 있다. 

 

 

스프링 플랫폼의 이점에 대한 예제

• 트랜잭션 API를 사용하지 않고도 데이터베이스 트랜잭션에서 자바메소드를 실행하도록 만든다.
• 원격 API를 사용하지 않고도 로컬 자바메소드를 원격 프로시저로 만든다
• JMS API를 사용하지 않고도 로컬 자바메소드를 메시지 핸들러로 만든다.

출처: 

https://limmmee.tistory.com/8 [심플하게 개발]