POJO - Plain Old Java Object , EJB - Enterprise JavaBeans 란?

POJO

POJO(Plain Old Java Object)는 말 그대로 해석을 하면 오래된 방식의 자바에서 제공한 오브젝트를 의미한다. 

실제로 Java EE 등의 중량 프레임 워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운"객체를 만들게 됬기에 생긴 단어이다. 이후에 POJO라는 용어는 주로 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않은 자바 오브젝트를 지칭하는 말로 사용되었다. 스프링 프레임워크는 POJO 방식의 프레임 워크이다.

 

하지만, 위의 경우에만 POJO 라고 하는 경우가 많지만 좀더 꼼꼼하게 이야기를하자면 2가지가 더해져야한다.

 

첫째. 객체지향적인 설계원칙에 충실하도록 개발되어 있는지 여부이다.

POJO의 자바 오브젝트라는 것은 단지 자바 언어 문법을 지켜 만들었다는 뜻이 아니다. 객체지향 언어로서의 자바 오브젝트의 특징을 가지고 있는지가 중요하다. POJO 코드가 객체지향적인 원리에 따라 설계되어 있지 않고 더 나아가 적절하게 리팩토링하는 것도 어려운 구조라면 POJO로 개발했다는 것이 주는 가치는 거의 없다고 본다. 끊임없이 반복적으로 등장하는 템플릿 코드와 테스트하기 힘든 구조, 확장이나 재활용의 어려움 등이 코드에 그대로 남아있다면 EJB의 문제점을 여전히 가지고 있는 것이다.

 

둘째. 테스트 코드 개발의 용이성이나 테스트 코드를 잘 작성했는지의 여부이다. 

EJB를 버리고 POJO 기반으로 개발한다고 하면서도 여전히 수정-빌드-배포-테스트라는 방식을 탈피하지 못하고 있다면 EJB로 개발했던 시절과 대체 무엇이 다를까? 잘 만들어진 POJO 애플리케이션은 자동화된 테스트 코드 작성이 편리하다. 코드 작성이 편리하면 좀더 자주 꼼꼼하게 만들게 되고 반복적으로 실행할 수 있으므로 코드 검증과 품질 향상에 유리하다. 또한 잘 만들어진 테스트 코드 베이스가 있다면 리팩토링할 여유가 생겨 POJO 코드를 더 나은 설계구조로 변경할 가능성도 높아진다.

 

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

 

POJO를 지향하는 이유

스프링 프레임워크 이전에는 원하는 엔터프라이즈 기술이 있다면 그 기술을 직접적으로 사용하는 객체를 설계했다. 그리고 이러한 개발 방식이 전세계적으로 만연하고 있었다. 특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성을 떨어트리고 유지보수에 어려움을 야기했다. 또한, 특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지는 단점이 생겼다. 곧 객체지향인 자바가 객체지향의 장점들을 잃어가는 것이였다.

 

그렇기에 다시 한번 생긴 개념이 POJO이다. 본래 자바의 장점을 살리는 순수한 방식의 자바개체를 만드는 것이다.

 

 

 

EJB(Enterprise JavaBeans)

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

 

 

POJO의 오해

많은 사람들이 POJO를 getter와 setter를 가진 오브제트를 POJO라고 한다. 하지만 getter/setter를 가진 오브젝트가 POJO가 아니라 getter/setter를 가진 단순한 오브젝트는 POJO에 포함되는게 맞는 말일 것이다.

 

 

 

 

 

 

 

 

베타존 : 네이버쇼핑 스마트스토어