JAVA에서 POJO 란 무엇일까? POJO 뜻 !

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 
간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서   
해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. <!--more-->  
2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이   
사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다.   



“ 우리는 사람들이 자기네 시스템에 보통의 객체를 사용하는 것을 왜 그렇게 반대하는지 궁금하였는데, 간단한 객체는 폼 나는 명칭이 없기 때문에 그랬던 것이라고 결론지었다. 그래서 적당한 이름을 하나 만들어 붙였더니, 아 글쎄, 다들 좋아하더라고. ” - 마틴파울러

POJO라는 용어는 이후에 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다.
현재 우리가 사용하고 있는 스프링 프레임워크는 POJO 방식의 프레임워크이다.


그렇다면 POJO는 왜 등장하게 되었나?

엔터프라이즈 자바빈즈(Enterprise JavaBeans; EJB)는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다.

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

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




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



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




즉, 스프링 애플리케이션 = POJO를 이용해서 만든 애플리케이션 로직 + POJO가 어떻게 관계를 맺고 동작하는지 정의해놓은 설계정보

스프링의 주요 기술인 IoC/DI, AOP, PSA 는 애플리케이션을 POJO로 개발할 수 있게 해주는 기술들이다.


POJO의 조건

  • 특정 규약에 종속되지 않는다.
  • 특정 환경에 종속되지 않는다.
  • 단일 책임 원칙을 지키는 클래스

즉, POJO란 객체지향적인 원리에 충실하면서, 특정 환경과 규약에 종속되지 않아 필요에 따라
재사용될 수 있는 방식으로 설계된 오브젝트라 할 수 있다.


POJO의 장점

  • 특정 규약에 종속되지 않아 객체지향 설계를 할 수 있게 됨.
  • 특정 환경에 종속되지 않아 테스트 하기 좋음
  • 특정 규약에 종속되지 않아 로우레벨 코드와 비즈니스 코드가 분리되어 깔끔한 코드 작성이 가능

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

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





지금이라도 알고쓰자 자바, Spring!!

+ Recent posts