- 출처 : http://blog.naver.com/thtlsgkrtod/40055742326 -
POJO (Plain Old java Object) 를 해석하면 평범 자바 오브젝트라고 한다.
POJO를 이해 하기 전 POJO라는 단어가 만들어진 역사적 배경을 살펴볼 필요가 잇다. POJO는 마틴 파울러가 2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 만들어낸 말이다. 마틴 파울러는 EJB(Enterprise JavaBean)보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이 있는데도 왜 사람들이 그 EJB가 아닌 '평범한자바 오브젝트'를 사용하기를 꺼려 하는지에 대해 의문을 가졌다. 그리고 그는 단순한 오브젝트에는 EJB와 같은 그럴듯한 이름이 없어어서 그 사용을 주저하는 것이라고 결론 내렸다.
그래서 만든 단어가 POJO라는 용어인 것이다. POJO기반의 기술을 사용한다고 말하면 왠지 첨단 기술을 사용하는 앞선 개발자인 듯한 인상을 주기 때문인다.
POJO기반의 프로그래밍 기술이 EJB의 강력한 대안으로 등장했고 ,POJO 기반 프레임워크 ,POJO 애플리케이션을 위한 플랫폼 등이 점점 인기를 끌게 되었고, 결국 POJO가 배제하려고 했던 EJB는 POJO기반의 기술에 밀려 이제 레거시 기술로 사라질 위기에 처했다. 그렇다면 단지 EJB를 사용하지 않으면 모두 POJO라고 할 수 있을까? 그렇지 않다. POJO프로그래밍이라는 개념은 단지 "EJB가 아닌 자바"이상의 특징을 가지고 있는 프로그래밍 모델이다. POJO기반의 개발은 생각보다 단순하지 않다.
POJO를 좀더 이해하려면 EJB의 장단점을 함께 이해해야 한다. 그것은 POJO 프로그래밍이 다시 EJB시대이전으로 돌아 가자는 것이 아니고 ,EJB를 넘어 그보다 더 앞으로 나아가자는 것이기 때문이다.
EJB를 사용하지 말고 POJO를 쓰자는 것은 EJB이전의 방식으로 돌아 가는 것을 의미한다면 또 다른 문제가 발생 할 수 밖에 없다. 여전히 복잡한 로우레벨의 API를 이용해 코드를 작성해야 하고, 많은 기술적인 문제를 애플리케이션 코드에 그대로 노출시켜 개발해야 한다면 기껏 POJO로의 복귀 덕분에 얻는 많은 장점들을 놓칠 수 밖에 없다.
그래서 등장한 것이 POJO 기반의 프레임워크이다. POJO프레임워크는 POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주느 프레임워크이다. 나아가 이는 기존의 EJB에서보다 훨씬 더 세련되고 나은 방법이다. 데표적인 프레임웤 스프링 하이버네이트~!
참고로 스프링은 엔터프라이즈 서비스들을 POJO기반으로 만든 비지니스 오브젝트에서 사용할 수 있게 한다. 대표적인 선언적인 트랜잭션 서비스와 보안이다. 또한 EJB와 마찬가지로 오브젝트 컨테이너를 제공해서 인스턴스의 라이프사이클을 과리하고 필요에 따라 스레딩, 풀링 및 서비스 인젝션 등의 기능을 제공한다. 또한 OOP를 더 OOP답게 사용 할 수있게 하는 AOP기술을 적용해서 POJO개발을 더 쉽게 만든다.
POJO프로그램의 진정한 가치는 자바의 객체지향적인 특징을 살려 비지니스 로직에 충실한 개발이 가능 하도록 하는것이기도 하다.
내생각(원문 필자)을 적자면
평범한 자바 객체로 프로그래밍 하기라고 부르며, 침략적인 코드를 적지 않은 것이다.
쉽게 말해 implement 와 extends를 사용 하지 않으며
콤포지션과 인터페이스타입으로 프로그래밍 하는것(이건 레디 존슨)
특정 클래스의 concrete class가 되면 안되고, 구현 체도 되면 안된다.