스프링을 써야하는 이유

스프링을 써야하는 이유

• product, customer 를 하나하나 처리해주는 servlet(ProductController)으로 만들었지만,
  모든 요청을 처리해주는 servlet을 하나 만들어서 사용할 수도 있다. : dispatcherServlet
  
• controller는 무조건 controller interface를 부여한 하위클래스여야만 함 (execute메서드를 보면 HttpServletRequest, HttpServletResponse) return타입은 String.

무조건 controller를 오버라이딩 해야하다 보니까 메서드 이름은 무조건 execute, 매개변수는 위의 request, response & return String type 여야한다.
-> 이 구조가 간단한 프로젝트에는 괜찮은데 너무 규격화 되어있으니까 이 규격을 맞추기 위해서 response가 필요없어도, request가 필요없어도 가지고있어야 한다
-> "스펙이 강화되었다"라고 표현함 -> 유연한 컨트롤러가 필요하다. 메서드가 다양화되어지려면 결국 dispatcherServlet의 코드가 복잡해질 수 밖에 없음. 한쪽이 유연해지려면 한쪽이 복잡해져야함 -> 오버라이딩을 많이 해야함.

• 컨트롤러의 가장 앞에 DispatcherServlet이 있고 그걸처리해주는 customerController (login, signup 메서드), ProductController(list, info 메서드)가 있음
  • mapping역할을 해주는 config.properties (key=value로 key에는 uri, value에 클래스를 연결)가 있어야함.
  • jvm에 올려서 객체에 올리고, 해당 메서드를 찾아서 호출도 하고 매개변수도 전달하고 return 값도 받아와야함 -> dispatcherServlet이 모두 다 하기에는 벅차다.
    ➡︎ 이 역할을 해주는게 스프링 web MVC module. 그냥 uri와 class만 설정해주면 됨 알아서 요청한 것에 대해 매핑해줄 것.

Servlet/jsp 엔진이 하는 일

• 웹서버: tomcat, apache, iis
• 웹기술 : Servlet/JSP, PHP, .NET
  • 서버마다 사용할 수 있는 기술이 다름. 톰캣에는 서블릿/jsp를 실행할 수 있는 엔진(컨테이너)이 포함되어있음
  • 아파치 : php실행 DLL, iis는 .NET 실행 모듈 포함
• 아파치나 iis를 안쓰는 이유는 servlet/jsp를 실행시켜줄 수 있는 컨테이너, 엔진이 포함되어있지 않기 때문!!
• 레진이라는 서버도 servlet/jsp를 가지고 있지만, 현업에서 안쓰는 이유는 유료여서.
• 성능이 좋은 웹 서버 (톰캣은 잘 죽기도함): 웹로직/ 웹스피어/ 제우스(티맥스) -> 고가!, 톰캣과 레진보다 안정성도 뛰어나고 기본 웹서버 역할을 넘어서 애플리케이션 서버 역할도 함
  • 애플리케이션 서버 ? (= 미들웨어) -> 미들웨어 ? 개발자가 직접 개발로 해결하지 못하는 문제를 서버가 대신 해결 (많은 사용자의 병목현상!!!을 알아서 관리해주는 서버, 놀고있는 서버에 접속시켜주는)
  • 미들웨어로는 웹로직을 쓰고 웹서버로는 톰캣을 사용하는 것처럼 연동해서 사용하는 경우도 많다.
  • 미들웨어 제우스 + 웹서버 WebToB 연동해서 사용하기도 함
    -> 여기서 미들웨어의 역할은 서블릿/jsp엔진, 웹서버는 웹서버 자체로만 역할함
• 미들웨어이면서 웹서버의 역할(애플리케이션 서버)을 하는 애들 => WAS/ 웹로직, 웹스피어, 제우스
  • 엄밀히 말하면 톰캣은 WAS의 역할을 하진 않음. 웹서버의 역할만 함
  • 티켓팅같은 많은 사람이 모일 때 트랜잭션 락을 걸고, 티켓팅 후 트랜잭션 락을 푸는 트랜잭션의 처리속도를 조절해주는게 was의 역할
    -> 웹로직 제품이 가장 트랜잭션처리가 빠름, 제우스는 가성비 좋음

• 톰캣구동 -> 웹 컨텍스트별 servletContext객체(api용 객체) 생성(알아서 자동 생성 : servlet/jsp의 도움을받은 것)
  • 웹 컨텍스트(비슷한 것들 끼리 모아놓은 것) = 웹모듈 = 웹어플리케이션
• servletContext : map타입의 멤버변수를 가짐
  • param(String=String) , attr(String=Object: value가 Object)
    
  • web.xml에 < context-param>을 만들 수 있는데, 하위에 < param-name>, < param-value>를 만들 수 있음. -> web.xml에 설정해놓으면 알아서 읽음.
    

• 웹 요청(/product/list?currentPage=3)이 들어오면 톰캣 엔진이 서블릿/jsp엔진 또는 컨테이너에 의해 servlet 객체는 생성된다.

• 개발자가 @WebServlet("product/list") 로 설정하던지 또는 web.xml에 < servlet>< servlet mapping>설정하면(둘중하나만하면됨) 서버가 알아서 servlet클래스를 찾고 서블릿클래스타입의 객체를 생성한다. -> 생성자 호출 -> init()메서드 호출 -> -> HttpServletRequest객체 생성, HttpServletResponse객체 생성(없으면) -> service( , ) 호출 -> 메서드 형식에 따라 doGet, doPost 메서드 호출
  ↳ 모든 작업을 servlet/jsp 엔진이 알아서 해줌!
  

• web.xml에 < init-param> < param-name> fileName < param-value>a.txt 로 설정해주면
  httpServlet에 param의 key(param-name)=value(param-value)형태로 들어감
  param이 잘 등록되기 위해서는 servletContext와 먼저 연결이 돼야함(init메서드가 servlet과 sevletContext를 연결 해줌)

• 생성자 호출시 객체 생성과 초기화까지는 되는데, servlet으로서 효과!를 내기 위해서는 또다른 메서드가 필요함 -> init()

• servlet의 sc메서드가 servletContext와 연결됨

• HttpServletRequest에도 param, attr메서드가 있음

• servlet에는 attr이 없고, sc랑 param만 있음
  

• HttpServletRequest : 응답시에 소멸

• Session: 최종 사용 후 30분 후에 소멸 (자소서 쓸때 30분후 로그인 풀리는게 세션써서....)

• servlet : class파일이 리로드(변경)될 때 소멸 -> destroy() 호출

• servletContext: 톰캣 중지시 소멸

• src/main/java or src/main/resources에 파일을 넣어서 배포가 되는게 아니라, build.classes에 옮겨지고 -> build.classes가 실제 톰캣서버에 붙여넣기됨

• resources폴더를 소스폴더로 설정하는 이유 ? build - > 소스폴더로 설정해야 build.classes에 연결되고 배포할 수 있게됨

• ibatis는 apache가 처음 개발 -> 구글로 넘어가면서 mybatis가 됨