forward
: '서버 내' 에서 응답할 페이지가 전환되는 기법
즉, 클라이언트에 이동할 페이지를 알려주지 않고 서버 내에서 바뀌기 때문에
클라이언트는 페이지가 바뀐 것을 알아차리지 못한다
또한, forward의 가장 큰 특징은 request가 유지 된다는 점이다
cf_ redirect는 유지가 안됨
<사진 설명 ↓>
1) 클라이언트가 요청을 함
2) server안에 있는 ok.jsp에게 요청(request)을 보냄
3) ok.jsp가 자기한테 없다고
받은 내용을 dok.jsp에게 요청을 넘김
4) dok.jsp가 ok.jsp에게 받은 내용이 있으니
그 내용을 토대로 client에게 응답(response)함
5) 하지만 request에 대한 정보는 보낼 수 없음
(받는 내용은 있지만 이 내용을 보내겠다고 할 수 있는 import나 처리할 능력이 없으므로,
만약 꼼수를 써서 만들어준다면 가능할지도..?)
사용 이유)
1. 요청을 받는 페이지와 응답을 하는 페이지가 별도로 관리되어야 하는 경우
2. MVC2, Spring MVC에서 1번의 경우를 사용한다지금 사용하고 있는 JSP는 MVC1로 사용중이다.
MVC1은 forward가 딱히 필요없다.
1) MVC1은 유지/보수가 좋지 않다(뒤에 설명)
2) 사용이유의 두번째는 초보자가 만들기 어렵다
MVC
: Model View Controller
Model - 데이터베이스
View - 사용자에게 보여줄 페이지
Controller - 요청을 받아 처리하는 것
- MVC1
: 간단하게 프로젝트를 만들 수 있지만
역할분담이 되어있지 않아
에러등 이상현상이 발생하면 처리하기가 힘들다
보통 소규모 프로젝트나 수업등을 할 때 많이 쓰인다
user ---request---> (view+model) ---response---> user
유저가 요청하면 하나로 묶어서 처리하고 응답해주기 때문에
개발자의 입장에서는 편리할 수 있다.
*oh...
하지만 이렇게 구분없이 그냥 사용하게 되면
확장을 하거나 재사용해야하는 코드, 에러를 찾기가 힘들어진다
MVC2에서는 위의구분없이 그냥 사용하는 부분을
구분을 하여 사용하게 되는 형태인데
디비 + 화면 + 제어가 하나의 묶음이였던 MVC1의 형태를
다시 나누어
디비, 화면, 제어 를 각 각 관리할 수 있게 만들었다.
user가 request하면
servlet이란 controller로 요청을 받아 parameter을 저장했다가
1) View로 출력해주거나
2) Moder을 통하여 Java Bean에 접근하여
DB와 데이터를 주고 받은 뒤
View로 가서 데이터를 주는 형태던지
1 요청을 받고 처리하는 부분은 Controller에서
2 필요하다면 DB에 접근하는 Model을 통해서
3_ 출력만 필요한 View를 통해서
구분해서 처리를 하기 때문에
에러 발생 시
DB가 이상하다 -> Model만 고치면 됨
요청이 이상하다 -> Controller만 고치면 됨
화면이 이상하다 -> View만 고치면 됨
※ 요즘에는 프레임 워크로 발전이 되어서
대표적으로 스프링 프레임워크를 쓰는데
프레임워크란?
반제품 이라고 생각하면 됨
완성은 안되어 있는데 대충 가공은 끝나있는 것
ex) 조립가구, 밀키트
밀키트를 예시로 들자면
만약 짬뽕 밀키트를 구매했으면
짬뽕에 대한 재료들이 다 손질되어서 제공될것이다
그런데 이 짬뽕 밀키트를 이용하여 탕수육을 만들지 못하는 내용이
프레임워크 라는 것인데
뭔 이상한 소리냐하면
짬뽕을 위한 재료는 짬뽕을 만들기 위해 존재하고
그 기본적인 조리 틀이 있고 그에 필요한 재료를 제공하는 것이 짬뽕 밀키트인데
같은 밀키트라고 짬뽕을 탕슉으로 바꿀 수 없다는 의미이다.
즉, 기본적인 틀이 정해져 나오니
그 틀대로 쓰고 이외로 사용은 불가능하다 라는 뜻이다
https://chanhuiseok.github.io/posts/spring-3/
자세한 내용은 여기를 참고해보자
그림들 출처임
