Java2EE Framework/Spring 2.0

Non EJB 개발 방식의 장단점

본클라쓰 2010. 5. 30. 19:25

■ Non EJB 개발 방식의 장점

 

 추가적인 교육 없이 초보 개발자들이 쉽게 이해하고 개발하는 것이 가능하다. 프로그램에 대한 깊이 있는 지식이 없는 개발자들이 쉽게 접근할 수 있는 개발 방식으로 초기 개발 속도가 빠르고 단기적이고 가시적인 성과를 낼 수 있는 방식이다.

 

 또한, 굳이 값비싼 EJB 컨테이너가 아닌 서블릿 컨테이너만으로 운영하는 것이 가능하다. 이는 EJB 컨테이너보다 서블릿 컨테이너가 이식성(Portability)이 훨씬 좋기 때문에 추후에 컨테이너가 바뀌더라도 손 쉽게 대응할 수 있다.

 

 또한, EJB보다 개발 주기가 짧기 때문에 개발 생산성의 향상을 가져올 수 있으며, EJB 의 경우 애플리케이션이 변경될 경우 개발, 빌드, 배포, 테스트 과정을 거쳐야 하지만 Non EJB 방식은 개발, 테스트 과정을 통해 개발하는 것이 가능하다.

 

 

■ Non EJB 개발 방식의 단점

 

 초기 개발 속도가 빠르지만 프로젝트가 진행되면서 추가 요청사항이나 변경사항이 발생할 경우 대응 속도가 느려 프로젝트 후반으로 갈수록 개발 속도가 느려지게 된다. 물론 명확한 계층 분리와 견고한 설계가 바탕이 된다면 이 같은 문제점을 극복할 수 있다. 하지만 명확한 계층 분리를 하기 어렵고, 계층 분리가 명확하지 않기 때문에 중복되는 코드가 많이 발생할 수 있다. 이로 인해 유지 보수 비용이 높다.

 

 또한, 일관된 개발 방식을 가지기 어렵다. 이 아키텍처를 이용할 경우 한 회사내에서 진행하는 프로젝트마다 서로 다른 아키텍처로 개발을 진행하는 경우가 많기 때문에 유지보수 비요의 증가를 가져온다.

 

 Non EJB 방식은 외부 시스템과 인터페이스하기 위한 분산 환경을 지원할 수 없다. 현재는 비즈니스 계층을 명확하게 분리하여 재개발해야 하는 경우도 발생하며 최근 웹 서비스 같은 기술이 등장하고, 외부 시스템과 연결 필요성이 점점 더 증가하는 시점에 비즈니스 계층이 독립적으로 분리되어 있지 않다면 분산 환경을 지원하기 더더욱 힘들다.

 또한, 비즈니스 로직을 구현하고 있는 비즈니스 객체의 생명주기를 프로그램에서 직접 관리해야 한다. 서블릿과 EJB의 경우 빈의 생명주기를 컨테이너에서 관리하는 것이 가능하다. 그러나 POJOs에 대한 생명주기는 프로그램에서 개발자들이 직접 관리할 수 밖에 없다.

 

 또한, EJB가 지원하고 있는 선언적인 트랜잭션과 같은 기능을 사용할 수 없다. 애플리케이션을 개발하면서 상당히 많은 시간을 투자해야 하는 부분이 트랜잭션 처리이다. 그러나 Non EJB 아키텍처는 프로그램에서 직접 작성하여 트랜잭션을 처리할 수 밖에 없다.

 

 역시 Non EJB개발방식의 가장 큰 단점은 계층을 구분하기 힘들다는 것이다. 계층을 비즈니스, 퍼시스턴스, 도메인 모델 등으로 구분했다 하더라도 계층간 영역이나 역할을 정의하기 힘든 개발방식이다. 단적인 예로 트랜잭션이나 조인을 둘 수 있다. 조인의 경우 여러 테이블에서 데이터를 읽어와야 하는데 퍼시스턴스 계층은 하나의 테이블에서 동작하는 영역이다. 그렇다면 여러 테이블에서 데이터를 읽어 올 때는 어느 계층에서 담당하는 것이 맞을까? 하는 문제부터 트랜잭션의 처리는 어느 계층에서 해야 하는 것이 맞을까? 하는 문제등 계층을 구분하기 어려운 단점이 있다.