[면접준비] MVC Model1, Model2

1. Model 1 방식

디자인코드 (HTML)와 자바코드(비즈니스 로직)를 구분하지 않고, 하나의 JSP 파일 내에 기술하여 개발하는 방식

장점 : 쉬운 개발, 낮은 학습 비용

단점 

 (1) 디자인코드와 자바코드의 경계가 명확하지 않아 높은 복잡도

 (2) 디자인코드와 자바코드가 하나의 파일에서 관리되기 때문에 자바코드를 수정할 때도 디자이너와 별도 협업이 요구

 (3) 비즈니스 로직의 재사용성이 낮으며, 중복 존재

 (4) 유지보수의 어려움 존재

2. Model2 방식

MVC 패턴을 적용하여 각각의 역할을 나누어서 개발이 가능 

 - Model : 비즈니스 로직을 담당하는 영역 (Model 1 방식과는 달리 디자인코드와 비즈니스로직을 분리)

 - View : 사용자가 사용하는 영역이며, Model에서 생성된 Data를 Client에게 보여주는 역할을 담당

 - Controller : 사용자의 요청을 받아서 요청에 따른 비즈니스 로직을 처리하도록 지시하며, 사용자에게 보여줄 화면을 받아서 전달하는 역할 담당

장점 : 디자인코드와 비즈니스 코드의 분리되어, 비즈니스 코드의 재사용 가능하며, 확장성, 유지보수, 중복제거 가능

단점 : Model 1 방식에 비해 초기 설계에 많은 시간 소요. 개발자에게 MVC 패턴 학습 필요

3. Model 2 방식 과 비교했을 때, Spring 편의성

(1) DB 처리의 편의성

 - Model 2 방식은 Database 처리 과정에서의 rollback 및 commit과 같은 트랙잭션 처리 및 Database 연결해제 작업을 직접 해줘야하는 불편 존재

 - Spring은 트랜잭션 처리 및 연결해제를 직접해주기 때문에 편의성 존재

(2) 컨트롤러 정의

 - Model2 방식은 하나의 클래스가 하나의 페이지를 담당하기 때문에 페이지의 수가 증가하면 관리해야 하는 컨트롤러의 수가 증가

   (@WebServlet 어노테이션을 이용해서 URL Mapping)

 - server-context.xml 파일에 Controller, Service 계층의 구현체를 직접 명시하면, 구현체는 자동으로 할당된다.

   @Controller 어노테이션을 이용해서 정의 가능하며, 하나의 컨트롤러에 여러 페이지에 대한 처리 가능

4. Spring 과 Spring Boot 편의성 비교

스프링과 스프링 부트를 차이를 물어본다고 한다면, 스프링 본래 목적에 충실하는 유무의 차이라고 말할 것이다. 

스프링의 개발된 본래 목적은 개발자가 자주하는 로우레벨의 실수를 줄이고, 개발에만 집중하여 편의성과 생산성을 높이는 것이 목적이다.

스프링 부트는 스프링에 비해 개발 시, 셋팅해야할 부분을 자동으로 제공함으로써 개발의 편의성을 더 제공하고 있다.

 (1) 설정의 간소화

 디스패쳐 서블릿을 자동 등록이 가능하다. application.properties에 설정들을 저장해두고 클래스에서 읽어 설정을 간편하게 해줄 수 있다. 

 application.properties에서는 다국적 셋팅이나, prfix, suffix 설정 가능하다. 스프링에서는 web.xml에서 모두 관리했는데, 서비스에 필요한 설정을 나눔으로써 

 관리 측면에서도 편의성을 제공했다.

 (2) 임베디드 서버

 단독 어플리케이션만으로 배포 가능하다. 과거에는 was 서버에서 구동 가능한 war 파일을 생성해서 배포했다. 또한 프로젝트와 서버의 버전을 동일하게 맞추고 관련 값에

 대해 설정이 필요했다. 불편했다.  그러나 스프링부트는 서버를 내장하고 있기 때문에 jar 파일만으로도 실행 가능하며, 배포 가능하다.

 (3) 간편한 의존성 관리

 사용하고 싶은 의존성에 대해 호환성을 고려하지 않아도 된다.

 SpringFramework 시절엔 Freemarker를 사용하기 위해선 Freemarker의 몇 버전과 Spring의 몇 버전이 호환이 되는지, 추가로 어떤 의존성이 필요한지 확인하는 과정이 

 꼭 필요했다. SpringBoot의 의존성 시리즈인 starter의 경우엔 사용하고 싶은 의존성이 Freemarker라면 spring-boot-starter-freemarker만 추가하면 그외에 어떤 의존성도 

 필요없다. starter 시리즈의 의존성이 버전, 추가의존성에 대한 호환성을 모두 보장하기 때문이다. 필요없는 의존성 혹은 교체하고 싶은 의존성이 있다면 제외시킬수 있다.