중복 소스 코드를 줄여줄것 같습니다. 

프론트 컨트롤러를 사용하지 않으면 여러 개의 서블릿이 필요하고 프로그램은 서블릿에 종속적인 프로그램이 될 것 같습니다.

또한 모든 요청을 하나의 서블릿에서 관리하기 때문에 개발 효율성이 증가합니다.

프론트 컨트롤러가 요청을 모두 받아서 위임해준다면, 필터링의 역할을 해줄 수 있을 것 같습니다..

예를들면 클라이언트의 잘못된 요청등에 대한 예외처리와 같은 Controller호출에 필요한 공통 작업을 제어할 수 있다는 장점이 있지않을까요..??

장점이 어떤 것이 있을지 생각해보기 위해 프론트 컨트롤러가 없을 경우에 불편함을 생각해보았습니다.

view에서 요청이 들어왔을 때 컨트롤러로 이동하게 되고 그 컨트롤에서 바로 로직을 처리하게 됐을 때, 1개의 요청 당 1개의 url을 가진 서블릿을 만들어야합니다. 이렇게 되면 유지 보수적인 측면과 코드 가독성, 개발의 효율이 떨어 질 수 밖에 없습니다.

따라서  프론트 컨트롤러라는 서블릿을 만들어 클라이언트의 요청을 한 곳으로 집중 시켜, 개발 및 유지보수에 효율을 극대화 시키는 방법을 사용하는 것입니다.

웹 애플리케이션을 개발할 때 사용하는 MVC 디자인 패턴은 뷰에서 요청이 들어왔을 때 요청을 받아 처리하는 것은 컨트롤입니다. 그런데 하나의 웹 애플리케이션에는 많은 뷰와 컨트롤러가 존재해서 각각의 뷰와 컨트롤러가 연결되어 독립적으로 실행되면, 서버 입장에서는 현재 웹 애플리케이션 실행에 대하여 일괄적으로 처리하기 어렵습니다.

이럴 때 대표 컨트롤러(Front Controller)를 두고 뷰에서 들어오는 모든 요청을 담당하여 웹  애플리케이션을 실행하는 모든 요청을 일괄적으로 처리할 수있습니다.

이러한 구조를 '프런트 컨트롤 디자인 패턴'이라고 합니다.

출처 : https://opentutorials.org/module/3569/21219

생각해보기 : 

model 1의 JSP는 view와 Controller 기능을 섞어 놨기 때문에 유지 보수가 힘들다.

Controller기능을 분리 하면서 디자인과 개발의 구조화로 유지 보수가 수월하며 역할과 책임의 구분이 명확해진다.

모든 요청을 한 곳에서 처리 하기 때문에 작업이 수월해지며 파일구조가 바뀌어도 URL 유지 가능하다.

감사합니다.