Spring boot실습 FrontController 패턴의 이해!(MVC패턴)

FrontController 패턴 

url 패턴은 자원을 디렉트로 찾는 모델 원 방식이다.

아피치(서버) 톰캣(was)이 하나의 서버를 실행하면 서버 안에 리소스(자원)가 있다. 이 리소스에 접근 시에 url방식을 사용하면 다이렉트로 주고받는다 이때 GET 방식으로 자원을 요청하면 응답 시에 text/html타입으로 응답해준다. 이때 웹 애플리케이션 서버(was)의 목적은 컴파일하는 것이다. java 관련된 파일을 요청할 때만 아파치가 아닌 톰캣이 일을 하는 것이다. 

이때 자바 코드에 DB에 커넥션 코드가 있다고 가정을 해볼 때  모델 원방식의 단점을 볼 수 있다.

 

-첫 번째로 파일마다  url을 연결해 줘야 하여서 일이 너무 많아진다. 파일마다 DB커넥션을 해야 하기 때문이다. 겹치는 코드가 많아짐

 

-두 번째 첫 번째 이유로 인해 수정 시에 복잡도가 올라간다.

 

servelet은 자바코드 안에 html을 쓰는 것

단점은 자바 코드 안에 html 코드를 넣자니 프로젝트가 커질수록 코드를 작성하기가 너무 불편하다.

jsp는 html 안에 자바 코드를 작성하는 것

그래서 html안에 자바 코딩을 하기는 편하다.

 

그래서 jsp로 코딩을 한 파일을 톰캣이 컴파일할 때는 jsp파일을 컴파일하기 위해서 servelet으로 변환되는 것이다.

jsp->java->html(MIME타입)

 

그래서 위 단점을 보완한 것이 uri패턴

클라이언트가 자원에 접근하는 것이 아니라 servelet에 접근하게 하는 것 모델 투 방식

그것이 FrontController이다. 위 겹치는 DB커넥션 코드를 이 servelet에 넣음으로써 중복을 없앨 수 있다

frontController의 책임은 라우팅(최적의 경로를 찾아내다) 하는 것, 이때 요청 시에 리다이렉션 되면서 응답이 2번 된다. 

그래서 frontControler(C) 같은 애들을 분기라고 하고 서버 내부에 있는 파일들을 그림(V)이라고 한다.

모든 요청을 분기에서 받아야 컨트롤하기가 좋기 때문에 분리된 것이다.

행위는 책임이다. 책임을 지게 할때는 하나의 책임만 지게 하고 거기서 추가하고 싶은 더 복잡한 DB로직(M)은 또 분리해서 연결시켜야 하는 것이다.

파일을 요청할 때 C->V

DB파일을 요청할 때 C->M->V

그래서 위 내용을 MVC패턴이라고 한다.

MVC패턴을 즉 모델 투 방식이라고 함

스프링 프래임워크는 무조건 MVC을 사용하도록 강제한다.

 

디스패처

프런트 컨트롤러는 프로젝트가 커지면 보통 테이블마다 컨트롤러가 만들어진다. 그래서 컨트롤러가 많아지기 때문에 어떤 컨테이너를 접근해야 할지 곤란해진다 이때 스프링 자체적으로 디스페처라는 기능이 작동해서 어떤 컨트롤러를 어떤 상황에서 써야 할지 자동으로 관리를 해준다

즉 클라이언트는 디스페처에게만 요청하면 되는 것

디스페처가 요청을 파싱 해서 IOC컨트롤러에게 들고 간다 그 자원을 IOC컨트롤러가 컴포넌트 스캔을 하면서 해당 자원의 어노태이션을 찾아줘서 해당 함수를 실행시키는 것이다.

 

클라이언트가 요청을 할 때 불합리한 요청(공격성이 있는)이 들어오면 서버에 들어오는 첫 관문인 톰켓에 필터를 작성해서 톰캣에서 컴파일할 때 걸러내는 방법이 있다.

이때 톰캣에 들어오기 직전부터 이런 불합리한 요청을 관리하는 사람이 데브옵스라는 사람들이다.

왜냐하면 백엔드 개발자가 할 일이 너무 많아지고 힘들어진다. 그래서 분리해놓은 것

최근 기업이나 국가 중요정보들을 클라우드에 데이터를 저장하는 일이 많아지는 것도 그런 것 때문이다.