Spring FrameWork 목적 및 POJO 방식

 

Spring FrameWork 목적 

 

Spring FrameWork 의 특징을 좀 더 잘 이해하기 위해서는 스프링의 등장 배경을 이해하면 도움이 됩니다. 

 

Spring은 앞서 설명한 것처럼 기존의 자바 엔터프라이즈로 구현하는 프로젝트의 시스템 개발이 너무 복잡해졌고 복잡성을 해결하고 편의를 제공하기 위해 등장했습니다. 

 

※ 복잡성의 근본적인 이유 

 

1) 기술적인 제약조건과 요구사항의 증가

 

엔터프라이즈 시스템이란 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템을 말합니다. 엔터프라이즈 시스템은 많은 사용자의 요청을 동시에 처리해야하기 때문에 서버의 자원을 효율적으로 공유하고 분배해서 사용할 수 있어야 합니다.

 

또한 중요한 기업의 핵심 정보를 처리하거나 미션 크리 티컬한 금융, 원자력, 항공, 국방 등의 시스템을 다루기도하기 때문에 보안과 안정성, 확장성 면에서 도 뛰어나야 합니다. 따라서 뛰어난 성능과 서비스의 안정성이 요구되고 그런 점을 고려한 개발 기술이 필요합니다.

 

2) 엔터프라이즈 애플리케이션이 구현해야 할 핵심 기능인 비지니스 로직의 복잡성과 기술적인 복잡성 증가 

 

예전에는 기업 업무 중 회계처럼 복잡한 계산이나 빠른 분석 작업이 필요한 영역에서만 IT 시스템 을 활용했습니다.

 

하지만 갈수록 엔터프라이즈 시스템을 이용해 기업의 핵심 업무를 처리하는 비율이 늘어갔고, 점차 대부분의 업무 처리는 컴퓨터를 이용하지 않고는 아예 진행하기 힘들 만큼 엔터프라이즈 시스템에 대한 업무 의존도가 높아졌습니다.

 

또한 엔터프라이즈 기술의 세부 요소가 이해하기 힘든 방식으로 얽혀 있고, 그 때문에 쉽게 다루기가 어렵습니다. 

 

위와 같은 비지니스 로직과 엔터프라이즈 기술의 두 가지의 복잡성이 한데 얽혀 있는 것이 근본적인 원인이라고 할 수 있습니다. 

 

※ 복잡성의 해결책 

 

1) EJB

 

EJB는 이러한 두가지의 복잡성을 해결해고자 등장했고 개발자가 로우레벨의 기술적인 복잡함에 신경 쓰지 않고 비즈니스 로직을 효과적으로 개발하는 데 더 집중할 수 있게 하자는 목표가 있었습니다.

 

하지만 기존 EJB는 결과적으로 그런 목표를 달성하는 데 실패했습니다. 애플리케이션 로직을 담은 핵심 코드에서 일부 기술적인 코드가 제거된 건 사실이지만, 오히 려 EJB라는 환경과 스펙에 종속되는 코드로 만들어져야 하는 더 큰 부담을 안게 됐습니다. 이는 결국 더 큰 복잡성을 불러오는 결과를 초래했습니다. 

 

가장 치명적인 건, EJB라는 틀 안에서 자바 코드를 만들게 강제함으로써 자바 언어 가 원래 갖고 있던 장점마저 잃어버렸다는 사실입니다. EJB의 특정 클래스를 상속하게 함으로써 더 이상 상속구조를 적용하지 못하게 만들거나, 다형성 적용을 근본적으로 제한한다거나 하는 것들입니다. 이렇게 되면 개발자의 코드에 난입해서 지저분하고 복잡한 코드를 형성하게 됩니다. 이러한 방식을 침투적인 방식이라고 합니다.

 

2) Spring

 

스프링은 EJB의 실패를 교훈으로 삼아서 출발했습니다. EJB의 처음 목표와 마찬가지로 기술적인 복잡함을 애플리케이션 핵심 로직의 복잡함에서 제거하는 데 목표를 뒀습니다. 하지만 그 과정에서 EJB 처럼 개발자의 코드에 난입해서 지저분하고 복잡한 코드를 만들어버리는 실수를 하지는 않았습니다.

 

스프링은 EJB와 달리 비침투적인 기술을 이용했습니다. 이는 기술의 적용 사실이 코드에 직접 반영되지 않는다는 특징이 있습니다. 어딘가에는 기술의 적용에 따라 필요한 작업을 해줘야 하겠지만, 애플리케이션 코드 여기저기에 불쑥 등장하거나, 코드의 설계와 구현 방식을 제한하지는 않는다는 게 비 침투적인 기술의 특징입니다.

 

POJO(Plan Old Java Object)

 

* POJO 프로그래밍 방식 

 

"스프링의 핵심은 엔터프라이즈 서비스 기능을 POJO에게 제공하는 것뿐만 아니라 분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공하는 것이다." 라고 스프링의 핵심 개발자가 말했을만큼 POJO는 스프링에서 중요한 방식입니다. 

 

1) POJO란?

 

POJO는 Plain Old Java Object의 첫 글자를 따서 만든 약자입니다. 이 방식을 만든 마틴 파울러는 당시에 유행하던 EJB 처럼 복잡하고 제한 많은 기술보다는 자바의 단순한 오브젝트를 이용해서 애플리케이션의 비지니스 로직을 구현하고자 했습니다. 

 

2) POJO의 조건 

 

단순히 " EJB를 사용하지 않으면 POJO 방식이다! " 라거나 " 그냥 평범한 자바 오브젝트 아니야? " 라는 생각으로 접근 하기 보다는 다음과 같은 조건들이 충족되어야 POJO 방식이라고 할 수 있습니다. 

 

2-1) 특정 규약에 종속되지 않는다. 

 

POJO 방식은 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 합니다. 특정 규약을 따라 만들게 하면 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구합니다. (ex EJB) 

 

그럴 경우 자바의 단일 상속 제한 때문에 더 이상 해당 클래스에 객체지향적인 설계 기법을 적용하기가 어려워지는 문제가 생깁니다. 또한 규약이 적용된 환경에 종속적이 되기 때문에 다른 환경으로 이전이 힘들다는 문제점이 있습니다. 

 

2-2) 특정 환경에 종속되지 않는다. 

 

특정 환경에 종속적이어야만 동작하는 오브젝트도 POJO라고 할 수 없습니다.

 

예를 들면 EJB 3는 분명 이전 버 전의 문제점이던 규약에 따라 오브젝트를 만들어야 한다는 단점은 극복했습니다. 어떤 면에서 POJO에 가까운 설계와 구현이 가능해졌습니다.

 

하지만 여전히 JNDI라는 서버 서비스를 필요로 합니다. EJB 3 빈의 의존 오브젝트 정보는 JNDI를 통해 가져와야하기 때문입니다. 따라서 JNDI가 없는 환경에서는 그대로 사용하기가 힘듭니다.

 

이렇게 JNDI와 같은 특정 환경이 의존 대상 검색 방식에 종속적이라면 POJO라고 할 수 없습니다.

 

따라서 진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활 용될 수 있는 방식으로 설계된 오브젝트를 말합니다.

 

그런 POJO에 애플리케이션의 핵심 로직과 기능 을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있습니다.

 

3) POJO의 장점

 

3-1) 특정한 기술과 환경에 종속되지 않는 오브젝트는 그만큼 깔끔한 코드로 작성되고 유지보수가 쉬워지기 때문에 편의성이 높아집니다. 

 

3-2) POJO 방식으로 개발된 코드는 매우 유연한 방식으로 자동화된 테스트에 매우 유리합니다. 

 

3-3) 객체지향적인 설계를 자유롭게 적용할 수 있습니다. 

 

 

4) POJO 방식의 프레임워크 

 

대표적으로 스프링과 하이버네이트가 있습니다.