Servlet의 한계
불편한 HTML 처리
Servlet은 자바 파일이기 때문에 Html을 버퍼로 처리(HTML Syntax 사용 불가, String 또는 버퍼의 형태로 치환해서 사용) 해야하기 때문에 불편했습니다.
공통 코드 중복, 높은 개발 피로도
Servlet은 매번 Servlet interface를 구현(Http protocol의 경우 HttpServlet class를 상속)해야 하기에 공통 코드 중복, 높은 개발 피로도를 가지게되었습니다.
JSP (MVC model-1)
JSP는 HTML 파일안에 java를 사용함으로써 html 생성을 보다 쉽게 했습니다.
HTML파일이기 때문에 태그를 직접 사용 가능했으며 java는 <% %> 영역안에서 사용했습니다.
하지만 JSP 파일 하나에서 뷰 처리와 비즈니스 로직을 동시에 작성하게 되어, 파일이 점점 방대해졌고 여전히 비슷한 패턴의 코드가 반복되는 문제가 존재했습니다.
DAO
DAO(Data Access Object) 패턴을 도입해 데이터베이스 로직을 JSP에서 분리하는 경우도 있었지만, 여전히 JSP에서 직접 DB 연동 코드를 작성하는 사례도 많았습니다.
뷰와 모델을 약간 분리하긴 했지만 컨트롤러가 따로 존재하지 않고 모든 처리를 JSP가 담당했기 때문에 엄밀한 의미의 MVC는 아니었습니다.
그럼에도 불구하고 일정 부분 역할 분리가 이루어졌다는 점에서 Model-1이라는 이름으로 불랍니다
잠깐 정리해보기
자바에서 직접 HTML을 출력해야 했던 Servlet 방식은 작성이 번거롭고 반복 코드가 많다는 단점이 있었습니다.
이에 HTML과 자바 코드를 함께 사용할 수 있는 JSP가 등장했으나 비즈니스 로직과 뷰 로직이 한 파일에 뒤섞여 유지보수가 어려웠고여전히 반복 코드가 많다는 단점이 존재했습니다.
Java bean과 제대로 된 MVC의 등장 (MVC model-2)
> https://programmers.tistory.com/entry/JSP-MVC-model2기존 JSP에서 존재했던 문제를 해결하기 위해 MVC(Model-View-Controller) 구조가 도입되었습니다.
이 구조에서 View는 JSP, Controller는 Servlet, Model은 JavaBean을 통해 역할을 분리하였습니다.
JSP Bean
JSPBean은 getter/setter 메서드를 갖춘 순수 자바 객체(POJO)로 웹 애플리케이션에서는 폼 데이터 처리, 단순 데이터 전달, 로직 분리 등의 용도로 사용되었습니다.
또한 Jsp 파일 내에서 jsp:useBean, jsp:setProperty 태그를 통해 쉽게 접근할 수 있으며, 이를 통해 뷰와 비즈니스 로직 간의 의존성을 줄이고 역할을 분리하는 기초적인 모델 역할을 수행했습니다.
-
Java Bean은 원래 재사용 가능한 컴포넌트로 설계되었으며, GUI 개발에서 시각적으로 조립할 수 있는 Visual Bean으로 사용되기 위해 제안된 개념입니다.
하지만 Java의 GUI 생태계가 몰락하면서, Java Bean은 서버에서 최소한의 스펙만 갖춘 JSP Bean 형태로 재활용되었고, 주로 JSP에서 요청 데이터를 처리하는 용도로 사용되었습니다. -
POJO는 Plain Old Java Object로 EJB를 비판하기 위한 책에서 나온 용어입니다. (후대에 나온 용어)
-
다른 종속성 없이 순수한 JVM에서 사용 가능한 객체라고 생각하면 됩니다.
JavaEE와 EJB (Enterprise Java Bean)
MVC를 통해 관심사를 분리했지만, 거대한 프로그램에서는 아래 기능을 구현하기 위해 너무 복잡했습니다.
- 트랜잭션 관리
- 동시성
- 분산처리
- 보안
FrameWork에 위 기능들을 위임하고 개발자는 비지니스 모델에 집중하고자 나온 것이 JaveEE입니다.
JaveEE에서 EJB를 Model 계층에서 사용했으며 EJB들은 EJB container에 의해 관리되었습니다.
JavaEE, EJB의 문제점
고통 받는 개발자
EJB는 특유의 복잡함과 종속성(컨테이너 종속성)으로 높은 개발 난이도로 요구했습니다.
이는 비즈니스 자체의 복잡함과 기술적인 복잡함이 결합되었기 때문이었습니다.
개발자는 Java EE 스펙에 정의된 여러 인터페이스와 추상 클래스를 반드시 구현하거나 상속해야 했고
JNDI, 트랜잭션, 보안, 원격 호출(RMI/IIOP) 등 다양한 기술 요소를 함께 다뤄야 했기 때문에 단순한 비즈니스 로직을 구현하더라도 진입 장벽이 매우 높았습니다.
Java EE의 핵심 아이디어는 복잡한 것을 프레임워크에 위임하자 였지만 Container에게 위임하기 위해선 개발자가 복잡한 설정을 해주어야했습니다.
Java EE가 설치되어 있는 상용 어플리케이션 서버가 비쌌던 이유도 한몫 했습니다.
EJB에서 벗어나기 위한 노력
여러 프레임워크의 등장
위 문제점들로 개발자들은 EJB에서 벗어나고 싶어했고 Struts와 spring mvc와 같은 프레임워크가 등장하게 되었습니다.
이 밖에 여러 framework들이 다투었지만 결국 Spring이 대표적인 framework로 자리잡게 되었습니다.
Spring이 대표적인 framework가 될 수 있었던 이유
- EJB의 복잡성을 해결하면서도 강력한 기능 제공
- POJO 기반의 단순한 개발 모델
- POJO기반인 것이 EJB와 대비되는 핵심 포인트입니다.
- 유연하고 강력한 DI와 AOP 지원
- 모듈화된 아키텍처와 풍부한 생태계
- 테스트 용이성
- 활발한 커뮤니티와 우수한 문서화
- 서버 독립성과 실행 환경의 유연성
