일단 역할분리 개발역사를 찬찬히 살펴보면
TEMPLATE ENGINE: 동적인 웹페이지를 생성하기 위해 사용되는 도구.
1. SERVLET/JSP로 동적인 웹페이지 만들기.
-> 하지만 한 페이지에 모든 역할이 다 들어감. 요새는JSP 잘 안 씀.
2. MVC 패턴
-> Model View controller 패턴.
1) Controller: servlet에 해당하는 역할, http request를 전달받아 파라미터 검증
비지니스 로직을 실행하고, view에 전달할 결과를 db나 레포지토리에서 조회하여 model객체에 임시로 저장.
(그러니까 요청과 응답을 전달하는 다리?)
2) model: view에 출력할data를 저장하는 객체(아마 중간 택배상하차 공장 역할)
3) View: Jsp에 해당하는 영역.(아마 프론트앤드의 보여주는 역할)
사용자가 클라이언트를 통해 데이터 요청을 하고 (api요청) 요청 받는 역할인 servlet컨테이너는 httpserveltRequest, httpSetvletResponse객체를 생성.
설정된 정보를 통해 어떠한 servlet에 대한 요청인지 찾는다.
해당 servlet에서 service 메소드 호출 뒤 doget() or dopost()등의 메소드 호출.
->요 방식은 jsp로 한 페이지에 view와 응답요청등 모든 역할을 맡으니 책임이 너무 많아 유지보수가 어려움.
mvc 패턴은
데이터를 요청 응답 처리하는 servlet과 그 결과를 보여주는 view역할로 나눔.
그러니 이 방식에도 단점이 있는데, servlet에게 너무 많은 책임을 맡는다는 것과,
중복된 기능이 많다는 것(생성 servlet/view, 수정 servlet/view, 사정 servlet/view 이런 1:1 식이면 servlet에 중복되는 부분이 생길 수밖에 없음)
❓그럼 중복된 부분을 method로 빼면 되지 않나요?
❗역시 method 호출 자체가 중복이 되고, 작업량이 많아질수록 호출이 힘들어짐.
3. 프론트 컨트롤러 패턴
모든 요청을 하나의 프론트 컨트롤러가 받아 공통 기능 처리하고 각 xcontroller를 찾아 호출. 호출된 컨트롤러를 제외한 나머지는 사용하지 않아도 됨.
하지만 여기서도 문제!
컨트롤러의 return 형태가 다를 수밖에 없고, 그것을 front colntroller가 처리하는 것은 한계가 있고, 코드가 길어짐. 역시나 front의 책임이 늘어남.
그래서 고안된 것이
4. 어댑터 패턴
콘트롤러의 반환값을 front controller가 처리할 수 있게 변환하는 구조.
5. Spring MVC
위의 패턴들이 모두 적용된 현재 사용되는 패턴.
- handler=(필요한 기능의)controller
Spring Annotation
-
@Slf4j: 인터페이스, logback같은 라이브러리 제공.
-
@Controller: controller(handler) 만들때 사용
+과제 하는데,
JdbcTemplate 작동이 안돼서 계속 찾고 찾았는데, 그냥 인텔리제이 자체를 껐다 키니 되었다...아마 다른 프로젝트랑 sql이 충돌돼서 그런가?;; 암튼 역시나 허무하게 해결ㅎㅎ
