POJO에 관하여
POJO (Plain Old Java Object)란?
객체 지향적 원리에 충실하면서 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트이다.
조건
-
특정 규약에 종속되지 않는다.
자바언어와 꼭 필요한 API 외에는 종속되지 말아야 한다.
-
특정 환경에 종속되지 않는다.
비즈니스 로직을 담고있는 POJO 클래스는 웹이라는 환경 정보나 웹 기술을 담고있는 클래스나 인터페이스를 사용해서는 안된다. 나중에 웹 컨트롤러와 연걸되어 사용될것이라도 직접적으로 웹이라는 환경으로 제한해버리는 오브젝트나 API에 의존하면 안된다. 그렇게 되면 웹 이외의 클라이언트가 사용하지 못하기 때문이다. 비즈니스 로직을 담은 코드에 HttPServletRequest, HttpSession 와 관련된 API를 직접 사용하면 안된다.
-
객체 지향적 원리에 충실한다.
POJO는 객체 지향적인 자바언어의 기본에 충실하게 만들어져야 한다.
참고
POJO는 다음과 같은 것을 해서는 안된다.
-
미리 지정된 클래스를 extends 하는 것.
public class Foo extends javax.servlet.http.HttpServlet { ... } -
미리 정의된 인터페이스를 implements 하는 것.
public class Bar implements javax.ejb.EntityBean { ... } -
미리 정의된 Annotation 포함하는 것.
@javax.persistence.Entity public class Baz { ... }
POJO-compliant라고 기술된 많은 소프트웨어 제품이나 프레임워크들(persistence와 같은)은 실제로 미리 정의된 Annotation을 제대로 동작하는 기능을 구현하기 위해 필요로 한다.
이와같은 것들의 특징은Annotation을 추가하기 전에 POJO이고 Annotation을 제거했을 때 POJO 상태로 돌아간다면 POJO로 간주할 수 있다.
장점
● 로우레벨 코드와 비즈니스 코드가 분리되어 깔끔한 코드 작성이 가능하다.
● 테스트하기 편하다.
● 객체지향적 설계를 할 수 있다.
POJO 프레임워크
POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크이다.
ex) 스프링, 하이버네이트
EJB (Enterprise Java Beans)
기업의 IT 시스템에서 요구하는 것은 늘어가고, 자바의 기초적 JDK로는 한계가 있으며 J2EE 가 등장했지만 Servlet, JSP 만으로는 복잡한 엔터프라이즈 서비스를 개발하는데 부담이 있었다.
복잡도
기업의 업무 복잡도가 높아짐에 따라 시스템이 다뤄야 하는 비즈니스 로직 자체가 복잡해졌다.
사용자의 처리 요구를 빠르고 안정적이고 확장가능한 형태로 유지하기 위해 필요한 로우레벨의 기술적 처리 요구들 (트랜잭션 처리, 멀티스레딩, 보안 등…)
이러한 복잡도를 한 번에 해결하기 위한 코드를 작성하는데 부담이 점차 가중되었고 이를 해결할 방법이 필요했다. 이로인해 EJB가 등장하였다.
EJB 비전
애플리케이션 개발을 쉽게 만들어준다. 애플리케이션 개발자는 로우레벨의 기술에 관심을 가질 필요가 없다.
새로운 문제
EJB는 필요로 하는 것이 너무 많았고 복잡했다. EJB는 컨테이너 밖에서는 정상적으로 동작하지 않았고, 개발자는 수정-빌드-배포-테스트의 사이클을 항상 반복했다. 또한 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 포기해야 했다. EJB는 상속, 다형성 등의 혜택을 누릴수 없고 간단한 기능 하나를 위해서도 많은 인터페이스, EJB 의존적 상속을 해야했다.
EJB의 떨어지는 생산성, 불필요한 기술적 복잡도, 과도한 스펙 등으로 POJO 방식으로 돌아가게 되었다.
POJO 기반 코드인지 확인하기 위한 기준
-
객체지향적인 설계원칙에 충실하도록 개발되어 있는가?
-
테스트 코드 개발의 용이성이나 테스트 코드를 잘 작성했는지의 여부
잘 만들어진 POJO 애플리케이션은 자동화된 테스트 코드 작성이 편리하다.
댓글남기기