이 글은 공부를 하면서 알게 된 내용들을 기록하는 글 입니다. 오류나 고쳐야 할 사항들이 있다면 지적 부탁드립니다!
✅ Front-controller 패턴이란
Front-controller 디자인 패턴은 application으로 들어오는 모든 요청이 하나의 핸들러(single handler)에 의해 다뤄지며,
request를 처리할 적절한 핸들러로 보낸다(dispatched).
또한 front-controller는 dispatching mechanism(보내는 매커니즘)을 사용하기 위해 다른 `helper`들을 활용할 수 있다.
🔥 Front-controller 디자인 패턴의 UML 다이어그램
1. Controller
Controller는 시스템에 들어오는 모든 request(요청)이 제일 처음으로 만나는 지점이다.
Controller는 사용자의 authentication(인가)와 authorization(인증)을 처리하기 위해 helper 해당 작업을 위임할 수 있다.
2. View
View는 client에게 정보를 보여주는 역할을 한다.
view는 `model`로부터 정보를 받으며, `helper`는 화면에 정보를 띄우기 위해 model을 캡슐화하는 등의
3. Dispatcher
Dispatcher는 view management(view 관리)와 navigation에 역할을 가지고 있다.
user에게 다음에 어떤 view를 보여줄 것인지, 해당 자원(Resource)를 제어하기 위한 매커니즘 제공 등을 담당한다.
4. Helper
Helper는 view를 도와주거나, controller가 처리하는데에 도움을 준다.
따라서 helper는 다양한 역할을 하는데, view에 필요한 데이터를 저장하기, 중간에 사용되는 model 저장하기 등의 역할을 하기도 하며, 이러한 경우 helper를 value bean이라고 부르기도 한다.
🔥 Front-Controller의 장점
1. 한 곳에서 모든 처리가 가능하다.
요청이 들어올 때마다 Servlet을 찾아서 매핑해주는 과정이
Front-controller는 Web application의 모든 request들을 처리한다.
이는 controller가 분산되는 것을 막는 `중앙 처리식`이며, 사용자 추적 및 보안과 같은 어플리케이션의 전반적인 정책을 시행하는데에 유용하다.
2. Servlet에 대한 의존성에서 벗어날 수 있다.
Dispatcher-servlet이 등장하기 이전에는 HTTP 요청을 처리할 Servlet을 생성해야했기 때문에, 자연스래 개발자의 코드에 Servlet이라는 기술에 종속된다는 문제점을 가지고 있었다.
Dispatcher-servlet이 등장하면서 Servlet 구현의 책임을 가져갔기 때문에, 우리가 Spring boot를 통해 개발을 할 때에 Servlet에 대해 신경을 쓰지 않아도 되게 되었다.
✅ Dispatcher-servlet
Servlet과 Servlet container의 동작 방식을 되짚어보자.
Client로부터 Request(요청)가 들어오면 Servlet container가 요청을 처리할 servlet을 찾아 요청을 처리한 후, Response(응답)을 다시 Client에게 전달한다.
(자세한 내용은 이 포스팅을 통해 알아볼 수 있다.)
Spring MVC에서 Dispatcher servlet이 등장하기 전까지는, `web.xml`에 서블릿과 URL 매핑 정보를 모두 등록해줘야했다.
또한 Servlet을 호출할 때마다 한글 인코딩 처리와 같은 공통으로 처리해야하는 로직을 중복 작성해야 한다는 단점이 있었다.
servlet을 개별적으로 다루어 공통된 로직을 여러 번 작성하지 말고, 앞에 서블릿을 하나 두어 공통된 로직을 처리하게 하면 어떨까?
그리고 탄생한 것이 바로 Dispatcher-servlet이다.
Dispatcher-servlet 덕분에 `web.xml`에 대한 의존을 엄청나게 낮출 수 있었으며, front-controller 역할을 하여 공통적인 로직을 Dispatcher-servlet에서 처리할 수 있게 됨으로서 중복 코드들도 깔끔하게 사라졌다.
또한 HttpServlet 클래스에 대한 의존성 문제도 해결되어 `@Controller`, `@RestController`와 같은 어노테이션들도 사용할 수 있게 된 것이다.
(Dispatcher servlet의 동작 원리에 대해 더 자세히 알고 싶다면 밑의 포스트를 참고하시길 바란다!)
https://m42-orion.tistory.com/156
✅ 참고 자료 & 링크
- Front Controller Design Pattern
https://www.geeksforgeeks.org/front-controller-design-pattern/
- Servlet과 Dispatcher servlet에 대해 알아보자
- Dispatcher servler이 대체 뭐하는 녀석이죠?
https://souljit2.tistory.com/73
- DispatcherServlet(디스패처 서블릿, Front Controller)
https://okimaru.tistory.com/343
이 글은 공부를 하면서 알게 된 내용들을 기록하는 글 입니다. 오류나 고쳐야 할 사항들이 있다면 지적 부탁드립니다!
✅ Front-controller 패턴이란
Front-controller 디자인 패턴은 application으로 들어오는 모든 요청이 하나의 핸들러(single handler)에 의해 다뤄지며,
request를 처리할 적절한 핸들러로 보낸다(dispatched).
또한 front-controller는 dispatching mechanism(보내는 매커니즘)을 사용하기 위해 다른 helper들을 활용할 수 있다.
🔥 Front-controller 디자인 패턴의 UML 다이어그램
1. Controller
Controller는 시스템에 들어오는 모든 request(요청)이 제일 처음으로 만나는 지점이다.
Controller는 사용자의 authentication(인가)와 authorization(인증)을 처리하기 위해 helper 해당 작업을 위임할 수 있다.
2. View
View는 client에게 정보를 보여주는 역할을 한다.
view는 model로부터 정보를 받으며, helper는 화면에 정보를 띄우기 위해 model을 캡슐화하는 등의
3. Dispatcher
Dispatcher는 view management(view 관리)와 navigation에 역할을 가지고 있다.
user에게 다음에 어떤 view를 보여줄 것인지, 해당 자원(Resource)를 제어하기 위한 매커니즘 제공 등을 담당한다.
4. Helper
Helper는 view를 도와주거나, controller가 처리하는데에 도움을 준다.
따라서 helper는 다양한 역할을 하는데, view에 필요한 데이터를 저장하기, 중간에 사용되는 model 저장하기 등의 역할을 하기도 하며, 이러한 경우 helper를 value bean이라고 부르기도 한다.
🔥 Front-Controller의 장점
1. 한 곳에서 모든 처리가 가능하다.
요청이 들어올 때마다 Servlet을 찾아서 매핑해주는 과정이
Front-controller는 Web application의 모든 request들을 처리한다.
이는 controller가 분산되는 것을 막는 중앙 처리식이며, 사용자 추적 및 보안과 같은 어플리케이션의 전반적인 정책을 시행하는데에 유용하다.
2. Servlet에 대한 의존성에서 벗어날 수 있다.
Dispatcher-servlet이 등장하기 이전에는 HTTP 요청을 처리할 Servlet을 생성해야했기 때문에, 자연스래 개발자의 코드에 Servlet이라는 기술에 종속된다는 문제점을 가지고 있었다.
Dispatcher-servlet이 등장하면서 Servlet 구현의 책임을 가져갔기 때문에, 우리가 Spring boot를 통해 개발을 할 때에 Servlet에 대해 신경을 쓰지 않아도 되게 되었다.
✅ Dispatcher-servlet
Servlet과 Servlet container의 동작 방식을 되짚어보자.
Client로부터 Request(요청)가 들어오면 Servlet container가 요청을 처리할 servlet을 찾아 요청을 처리한 후, Response(응답)을 다시 Client에게 전달한다.
(자세한 내용은 이 포스팅을 통해 알아볼 수 있다.)
Spring MVC에서 Dispatcher servlet이 등장하기 전까지는, web.xml에 서블릿과 URL 매핑 정보를 모두 등록해줘야했다.
또한 Servlet을 호출할 때마다 한글 인코딩 처리와 같은 공통으로 처리해야하는 로직을 중복 작성해야 한다는 단점이 있었다.
servlet을 개별적으로 다루어 공통된 로직을 여러 번 작성하지 말고, 앞에 서블릿을 하나 두어 공통된 로직을 처리하게 하면 어떨까?
그리고 탄생한 것이 바로 Dispatcher-servlet이다.
Dispatcher-servlet 덕분에 web.xml에 대한 의존을 엄청나게 낮출 수 있었으며, front-controller 역할을 하여 공통적인 로직을 Dispatcher-servlet에서 처리할 수 있게 됨으로서 중복 코드들도 깔끔하게 사라졌다.
또한 HttpServlet 클래스에 대한 의존성 문제도 해결되어 @Controller, @RestController와 같은 어노테이션들도 사용할 수 있게 된 것이다.
(Dispatcher servlet의 동작 원리에 대해 더 자세히 알고 싶다면 밑의 포스트를 참고하시길 바란다!)
https://m42-orion.tistory.com/156
✅ 참고 자료 & 링크
- Front Controller Design Pattern
https://www.geeksforgeeks.org/front-controller-design-pattern/
- Servlet과 Dispatcher servlet에 대해 알아보자
- Dispatcher servler이 대체 뭐하는 녀석이죠?
https://souljit2.tistory.com/73
- DispatcherServlet(디스패처 서블릿, Front Controller)
https://okimaru.tistory.com/343
