1 POJO
- POJO는 Plain Old Java Object의 첫 글자를 따서 만든 약자다.
- EJB처럼 복잡하고 제한이 많은 기술을 사용하는 것보다 자바의 단순한 오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하는 것 좋다고 생각해 만들어진 개념이다
- "간단한 자바 오브젝트를 사용하는 것"에 세련된 이름을 붙인 것이 POJO다
2 POJO의 조건
- EJB를 사용하지 않으면 POJO일까? 특정 프레임워크의 클래스를 상속하지 않으면 POJO일까?
- POJO를 명확하게 정의한다면 3 가지 조건을 충족해야 POJO라고 불 릴 수 있다.
2.1 특정 규약에 종속되지 않는다
- POJO는 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 한다.
- EJB2와 같이 특정 규약을 따라 비즈니스 컴포넌트를 만드는 경우 POJO가 아니다
- 스트럿츠1과 같이 특정 클래스를 상속해서 만들어야 하는 규약을 따라 만든는 경우도 POJO가 아니다.
- 특정 규약에 종속시키기 위해 상속을 요구하는데 자바의 경우 단일 상속 때문에 더이상 해당 클래스에 객체지향 설계 기법을 적용할 수 없게 한다.
- 특정 규약에 종속되면 다른 환경으로 이전이 힘들다.
- 별다른 가치를 주지 못하는 규약에는 종속되지 않아야하고 객체 지향 설계의 자유로운 적용이 가능해야 POJO라 불릴 수 있다.
2.2 특정 환경에 종속되지 않는다
- 특정 환경에 종속되어야만 동작하는 오브젝트도 POJO가 아니다.
- EJB3는 JNDI라는 서버 서비스를 필요로 한다.
- EJB3 빈 의존 오브젝트 정보를 JNDI를 통해 가져오기 때문이다.
- 따라서 JNDI가 없는 환경에서 사용할 수 없다.
- 비즈니스 로직을 담고 있는 POJO 클래스는 웹이라는 환경정보나 웹 기술 을 담고있는 클래스나 인터페이스를 사용해서는 안 된다.
- 이렇게 되면 웹 외의 클라이언트가 사용하지 못하게 된다.
- 웹 서버에 올리지 않고 독립적인 테스트가 힘들어 진다.
- 비즈니스 로직을 담은 코드에 HttpServletReqeuest나 HttpSession, 캐시와 관련된 API가 있으면 진정한 POJO라고 할 수 없다.
2.3 객체지향의 충실
- 특정 기술규약과 환경에 종속되지 않으면 모두 POJO인가?
- 그렇지 않다.
3 POJO의 장점
3.1 간단함
- 로우레벨의 기술과 환경에 종속적인 코드가 비즈니스 로직과 함께 섞여 나오면 지저분하고 복잡하다
- 이러한 코드는 이해하기도 어려우며 테스트 작성도 어려워 유지보수의 큰 부담이 된다.
3.2 테스트 용이
- 특정 환경에 종속되지 않기 때문에 자동화된 테스트에 매우 유리하다.
- 환경의 제약은 테스트를 어렵게 하는데 EJB 2는 테스트를 위해 서버 구동 및 빌드와 배치 과정까지 필요하다.