자바의 경우 선택할 수 있는 프레임워크의 수와 다양성에서 타 언어를 압도한다. 아마 자바와 비견되는 다양한 프레임워크를 제공하는 언어는 PHP정도가 아닐까? (사실 갯수로만 따지자면 PHP의 프레임워크 수는 자바를 상회한다!!) 하지만 목적에 맞는 프레임 워크를 선택하지 못한다면 필요없는 학습 코스트와 런타임 오버헤드를 감수해야만 할 것이다.
The Curious Coder's Java Web Frameworks Comparison!에서는 프레임워크 선택에 대한 고려사항으로 다음과 같은 항목을 꼽고있다.
- 고속 프로토 타이핑 - 얼마나 빠르고 쉽게 프로토타이핑이 가능한가
- 기능 - 얼마나 많은 기능들이 제공되는가
- 사용성 - 얼마나 사용하기 쉬운가
- 인기도 - 많이 사용하는 프레임워크는 풍부한 도큐먼트와 커뮤니티의 지원을 기대할 수 있다
- 프레임워크 생태계 - 열성적인 오픈소스 커뮤니티의 지원을 받는 프레임워크들은 스스로 진화하고 확장해 나감으로서 보다 완벽한 모습을 띄게된다.
- 처리능력과 확장성
- 코드 유지보수와 업데이트의 용이성
- UX, Look and feel - UI관련 기능
오늘은 최근 프로젝트에서 사용한 프레임워크들에 대해서 느낀점을 간략히 정리해 보고자 한다.
Spring(SpringMVC) vs JavaEE(6또는7) vs Struts
Spring는 현재 자바 프레임워크의 대세이다. 1800건 이상의 개발자 설문조사를 바탕으로 작성된 Developer Productivity Report 2012에의하면 Spring은 30%의 시장점유율로 자바 프레임워크의 산업표준이라 할 수 있으며 실제 표준인 Java EE 6조차 DI 인젝션과 같은 아키텍쳐상의 주요 컨셉을 상당부분 차용하고 있는 실정이다. 차기 Spring 4.0에서는 역으로 한발 앞서 공개된 Java EE 7 주요 아키텍처 컨셉의 상당부분을 포용함으로서 두 프레임워크는 더욱더 닮은 모습을 띄게 되었다.
최신버전의 Spring과 JavaEE는 모든면에서 서로 닮은 모습을 하고 있으나 어플리케이션 서버의 선택에 있어서 매우 유연한 Spring에 비해 JavaEE는 JavaEE 지원 어플리케이션 서버에서만 구동이 가능하다. 게다가 JavaEE인증을 받은 서버라 할 지라도 특정 DB만을 지원하는 JPA 구현과 같이 세부 사양에 대한 구현방식이 약간씩 다른경우가 있으므로 프레임 워크 선택시엔 표준 사양 세부 항목들의 지원 여부를 따져보고 제약사항을 꼼꼼히 확인해야 한다.
결국 Spring과 JavaEE 양자간의 선택이라고 한다면 오픈 소스의 유연함과 확장성인지 개발 표준에 대한 신뢰성에 대한 선택이 될 수 있을것이다.
Struts는 초기 자바웹 프레임워크의 대표주자로 스마트UI가 주류를 이루었던 시절에 등장하여 오늘날의 MVC패턴이 자리잡는데 큰 역할을 하였다. 현시점에선 다른 프레임워크들에 비해 생산성이나 기능등의 많은 면 에서 뒤떨어지는 모습을 보여주고 있기는 하지만 오랜기간동안 많은 웹 어플리케이션들이 Struts 베이스로 만들어졌기에 오늘날에도 Spring과 JavaEE에 이어 시장점유율 3위를 차지하고 있다.
Hibernate VS JPA VS iBatis(myBatis)
이번엔 퍼시스턴스 프레임워크를 살펴보자. Hibernate는 대표적인 ORM 프레임워크이며 JPA는 퍼시스터스 사양이다. 잘 알려진 JPA의 구현으로는 Eclipselink와 Hibernate등이 있으며 JavaEE와 Spring에서 지원된다. 기존의 Hibernate ORM과 JPA의 가장 큰 차이점은 데이터 영속화에 대한 정보를 XML에서 관리하느냐 어노테이션에서 관리하느냐의 차이점과 관계형 데이터 베이스를 오브젝트가 보다 쉽게 사용할 수 있도록 한 HQL 과 Criteria Query의 존재라 할 수 있겠다.
HQL과 Criteria Query의 차이점에 대해서 Sivateja씨는 자신의 블로그에 다음과 같이 정리해 놓았다.
- HQL 은 데이터에 대해서 선택/비선택 작업이 모두 수행 가능하지만 Criteria는 단지 선택 작업만이 수행 가능하다.
- HQL은 정적 쿼리를 수행하기에, Criteria는 동적 쿼리를 수행하기에 적절하다.
- HQL은 페이징 컨셉을 지원하지 않지만 Criteria는 지원한다.
- Criteria는 일반적으로 HQL보다 수행속도가 느리다. (역자 주 : 이 부분은 최신 버전의 Eclipselink의 경우 차이가 많이 좁혀졌다.)
- Criteria는 동적으로 쿼리를 생성하기 때문에 안전한 SQL인젝션이 가능하다. 반면 HQL는 정적 쿼리이기 때문에 SQL인젝션에 대한 안전성이 보장되지 않는다.
대세는 점차 JPA로 옮겨가는 중인데, 자바 전체가 어노테이션을 지향하고 있다는 점 외에도, 도메인 주도 설계와 같은 도메인 모델 패턴에서 관계형 데이터베이스를 직접적으로 의식하지 않는 퍼시스턴스 레이어 설계가 가능하다는 점이 개발자들에게 받아들여지고 있다고 본다.
마지막으로 대표적인 SQL Mapper인 iBatis의 경우 기존 NativeSQL+JDBC 개발자들에게 친숙해서 많은 환영을 받는 반면 진정한 의미의 퍼시스턴스 레이어 구현과는 거리가 있다.
Transaction Script Pattern 개발에서는 iBatis 만으로도 충분히 대응이 가능하지만 Domain Model Pattern 개발시에는 ORM인 Hibernate나 JPA가 퍼시스턴스 층의 구현으로서 보다 나은 선택이 될 것이다.
Transaction Script Pattern과 Domain Model Pattern에 대한 설명은 최범균님의 블로그 포스트에서 상세히 설명하고 있으니 참고하기 바란다.
