Spring_Why?

지난 시간에 MVC 패턴을 직접 만들면서, 점점 더 개발자가 이용하기 편한 방식의 패턴을 만들었다.그리고 마침내 V5버전까지 가면서 현재의 MVC 패턴과 비슷하게 되었다. 이제 스프링 웹 MVC를 본격적으로 파헤쳐보자...! 우리가 만든 프론트 컨트롤러가 디스패쳐 서블릿이라 보면 된다.디스패쳐 서블릿도 부모 클래스에서 HttpServlet을 상속박아 사용하고, 서블릿으로 동작한다. 흐름: 서블릿 호출시 service()가 호출스프링 MVC는 디스패쳐 서블릿의 부모인 frameworkServlet에서 service를 오버라이드 해놨다.이걸 시작으로 여러 메서드가 호출되며 최종적으로 doDispatch가 호출된다 스프링 부트는 자동으로 여러 핸들러 매핑과 어댑터를 등록한다. 그중 자주 나오는 핸들러 매핑..

지난 시간, 스프링 웹 MVC 이전의 개발을 1줄 요약하면 다음과 같다. 동적 html 처리 -> 서블릿 등장 -> 서블릿은 Tcp 연결, 멀티쓰레드 등 문제해결 but 자바로 html 생성이 어려움 -> JSP -> 편하지만(공감 못함) 너무 많은 로직이 담겨있어 유지보수 에바 -> 둘 합친 MVC 패턴 -> 훌륭한데 중복이 너무 많음(공통처리가 어려움) 그래서! FrontController라는 것이 나왔다. 이제 FrontController가 어떻게 도입되고 편리를 제공했는지 잘 보자. FrontController는 말그대로 앞단에 컨트롤러를 두는 것이다.나중에 등장하겠지만 스프링 웹 MVC의 DispatcherServlet과 역할이 같다. 스프링 복습 포스팅 컨셉상, 그림을 최대한 빼려고 했는..

* 본 포스팅은 김영한님의 SpringMVC 강의를 듣고 내맘대로 요약해서 왜?에 초점을 맞춘 포스팅입니다.핵심: 막줄 지난 포스팅으로 스프링의 등장 배경과 핵심기능에 대해 살펴보았다.이번 시리즈에서는 스프링 MVC에 대해 자세히 알아보고자 하는데, 컨셉은 마찬가지로 왜? 에 맞춰볼 예정이다. 사실 나는 스프링 부트 2.x도 제대로 사용해본적 없이 3.0부터 본격적으로 개발을 시작했기 때문에, 이전 스펙에 대해 잘 모른다.당연히(?) 왜 Spring MVC를 사용하는게 편한지, 이전과 무엇이 달라졌는지도 몰랐다. 서블릿 태초에 웹서버가 있었다...Web Server → 정적 리소스 제공 (Nginx, apache)WAS → 웹서버 기능 포함,프로그램 코드 실행 → 로직 수행 가능(동적 HTML, ..

지난 포스팅에서 6장까지 알아보았는데, 6장까지는 핵심 원리에 가까운 내용이었다.이번 포스팅에서는 7장부터 끝까지, 스프링의 핵심 기능(물론 원리도 포함)에 대해 알아보자.  저번 포스팅을 보면서 "내가 생각한 핵심 원리"이라는 주제로 글을 포스팅한 것은 좋았는데, 막상 그걸 보았을 때 "어떤 도움"이 되는지 확실하게 생각해보지 못했다. Q: 그럼 쓸데없는 내용을 빼고 혼자 내용을 간추렸다는 건가요? 김영한님 강의를? 무슨 기준으로? 무슨 역량으로..?A: 물론 혼자 간추리면 뭐가 틀려도 단단히 틀릴 수 있겠지만,  그 내용을 여기 포스팅에 여실히 기록하기로 했다.내가 정리한게 다 맞을 필요도 없고(내가 복습할 내용인데 뭐) 무엇보다, 그래야 내가 공부했을 때 무엇을 잘못 이해했는지, 놓친 것은 없었는지..

* 해당 게시물은 김영한님의 [스프링 핵심 원리 - 기본편]을 공부하고 복습용으로 남기는 글입니다.  2년 전 처음 이 강의를 보았다. 그 때는 아 스프링이 이런거구나~하고 넘겼는데프로젝트를 한 두개쯤 하고 나니까 그제서야 스프링 이론이 군데군데 비어있는게 실감이 나서 복습겸 다시 정리해보았다.   1. 스프링의 등장 배경- EJB없이도 고품질의 확장가능한 객체 지향 개발이 가능하도록   2. 기존 자바 코드로 서비스를 확장할때의 문제점 (객체 지향 설계의 문제)의도: 인터페이스를 활용해 OCP,DIP를 잘 지키게 설계상황: 확장시 의존 관계 때문에 다른 코드로 바뀔 때 -> 추상 인터페이스뿐 아니라 구현 클래스에도 의존하게 되는 문제 (DIP 위반)-> 클라이언트 코드(`OrderServiceImpl등..