♪ 학습 내용 더 실용적이고 유연한 컨트롤러 개선 (model을 파라미터로 / 어댑터 패턴 적용) * model을 파라미터로 앞에서는 컨트롤러에서 ModelView 객체 생성하고 다시 반환해야했다. 어떻게 보면 귀찮은 작업..! 그래서 컨트롤러는 ModelView가 아닌 ViewName만을 반환하게끔 개선했다. 그렇다면 model은 어떻게 처리하지 ? 싶었지만 Map으로 구현한 model을 프론트 컨트롤러에서 컨트롤러를 호출할 때 파라미터로 넘겨주었다. 즉, 컨트롤러 입장에서는 파라미터로 넘어온 Map(model)에 데이터만 넣고, 반환은 뷰 이름만 반환하면 된다. 위의 프론트 컨트롤러에서 model 객체 (Map)를 생성하여 컨트롤러에게 파라미터로 넘기는 것을 확인 ! 그리고 논리 이름인 ViewNam..

♪ 학습 내용 MVC 프레임워크 개선( view 분리 / 컨트롤러의 서블릿 종속성 제거 / 뷰 이름 중복 ) * View 분리 앞서 만든 코드에서는 각 컨트롤러마다 다음 코드가 중복 작성됐었따. RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath); dispatcher.forward(request,response); 중복을 제거하기 위해 뷰 코드를 처리하는 MyView 객체를 만들었다. public MyView(String viewPath){ this.viewPath = viewPath; } viewPath를 생성자 파라미터로 가진다. 각 컨트롤러에서는 매번 forward 할 필요 없이 MyView 객체를 생성하고, 프론트 컨트롤러에..

♪ 학습 내용 프론트 컨트롤러란 ? / 프론트 컨트롤러 도입 * 프론트 컨트롤러 이전 학습에서 공통처리로 인한 MVC 패턴의 한계를 알아보았다. 기존에는 클라이언트가 직접 컨트롤러(서블릿)를 호출하므로 각 컨트롤러 마다 공통 로직이 필요했다(중복). 하지만 프론트 컨트롤러를 도입한다면 ? 프론트 컨트롤러를 도입함으로써 입구는 하나가 되었고, 모든 클라이언트의 요청은 프론트 컨트롤러만을 호출한다. 그리고 프론터 컨트롤러는 고객의 요청을 받고 이에 매핑되는 컨트롤러를 호출해준다. 궁극적으로는 프론트 컨트롤러에 공통 처리를 몰아서, 공통 처리하기 좋아졌다. 클라이언트의 요청을 받는 프론트 클라이언트는 서블릿이다. 그렇다면 나머지 컨트롤러는? 서블릿이 아니지만, 서블릿과 유사한 구조를 지닌 인터페이스로 구현한다..

♪ 학습 내용 MVC 패턴과 한계 * MVC 패턴 Model : 뷰에 출력할 데이터를 담는다. 따라서 뷰는 모델을 통하여 렌더링에만 집중 View : 모델에 담겨있는 데이터를 이용하여 화면에 렌더링 --> HTML 생성 Controller : HTTP 요청을 받아 비즈니스 로직 실행(서비스 계층 이용), 뷰에 전달할 데이터를 모델에 담는다 컨트롤러로 서블릿을, 뷰로 JSP를 사용했다!! 데이터를 담을 Model은 ?? request.setAttribute(); request.getAttribute(); HttpServletRequest 객체 내부에 데이터를 담음으로써 request 객체를 모델로 사용하였다. 대충 서블릿의 service에서 request에 데이터를 담고, JSP(뷰)에서 꺼내 사용! Re..

♪ 학습 내용 회원 관리 웹 애플리케이션 구현 ( 서블릿 / JSP ) / MVC 패턴의 필요성 * 회원관리 웹 애플리케이션 - 서블릿 회원 저장소인 MemberRepository는 싱글톤 패턴 적용 --> new 연산자 사용x 서블릿 호출 시 HTML Form을 만들어서 응답! HTML을 응답하니 HTTP 응답 메시지의 헤더를 다음과 같이 설정해주었다. response.setContentType("text/html"); response.setCharacterEncoding("utf-8"); 서블릿 로직을 보면 전송 버튼 눌렀을 때 /servlet/members/save 호출 서블릿만으로 회원 저장 애플리케이션을 구현해보았다. 개발함에 있어 불편했던 점은 w.write()로 HTML 코드를 넣어주어야 했..

♪ 학습 내용 HTTP 응답( HTTP Response) 사용 * HttpServletResponse 다음 메서드들을 이용해 Response 정보를 설정할 수 있다. setStatus로 HTTP 응답의 상태 코드를 설정! 숫자로 (200, 300 ..) 설정 가능하지만 아래처럼 표시하는 것이 좋다. response.setStatus(HttpServletResponse.SC_OK); //괄호 안은 200을 의미 setHeader로 response에 헤더 정보 설정!! HTTP 응답에서는 주로 다음 세가지 데이터를 전달. 1. 단순 텍스트 2. HTML 3. HTTP API - Json * HTTP 응답 데이터 - 단순 텍스트 단순 텍스트를 전달할 때에는 아래처럼 간단하게 전달 가능하다! * HTTP 응답 ..

♪ 학습 내용 HTML FORM 데이터 전송 / 메시지 바디에 직접 데이터 전송 * HTML FORM 데이터 전송 HTML의 FORM에 클라이언트가 입력한 데이터를 서버로 전송 !! POST의 HTML FORM을 전송하면 HTTP 메시지가 만들어지며 전달된다. content-type은 바디에 포함된 데이터가 어떤 형식인지 알려주는 헤더이다. message body에 들어갈 데이터가 있으므로 content-type이 있다. (GET url 쿼리 파라미터 조회 시에는 body 내에 데이터가 없으므로 content-type도 없다) 해당 content-type 형식(x-www-form)은 데이터를 쿼리 파라미터 형식으로 전달한다 GET url 쿼리 파라미터 조회와 똑같은 쿼리 파라미터 형식으로 데이터가 전달되..

♪ 학습 내용 HTTP 요청 메시지를 통한 데이터 전달 / GET - 쿼리 파라미터를 이용한 방식 * HTTP 요청 데이터 전달 HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달하는 방식은 다음 3가지를 주로 사용!! 1. GET 메서드 - 쿼리 파라미터 이용 2. POST 메서드 - HTML From 데이터를 HTTP 메시지 바디에 쿼리 파라미터 형식으로 전달 3. HTTP 메세지 바디에 데이터를 직접 담아 요청 ex) json, sml, text ...etc * GET - 쿼리 파라미터 전달 url의 쿼리 파라미터를 이용해 전달한다 "http://localhost:8080/request-param?username=hello&age=20&username=hello2" 서블릿 매핑(urlP..

♪ 학습 내용 프로젝트 생성 / 서블릿 기초 / HttpServletRequest 사용 / PostMan * 프로젝트 생성 * 서블릿 동작 방식 스프링 부트를 실행하면 내부에 서블릿 컨테이너를 가지고 있는 내장 톰켓 서버를 생성한다. 서블릿 컨테이너는 서블릿을 생성하고 관리한다. 웹 브라우저에서 요청이 들어오면 WAS는 위 그림과 같이 request, response객체를 생성, 해당하는(uri 매핑) 서블릿에게 객체를 넘겨 서블릿 내부 메서드를 실행한다. 서블릿은 파라미터로 들어온 HttpServletRequest와 HttpServletResponse를 가지고 비즈니스 로직(service 메서드)을 실행. 그 과정에서 response 객체에 필요한 데이터를 담는다. 로직 종료 후에는 WAS가 이 res..

♪ 학습 내용 WAS / 서블릿(컨테이너) / 멀티쓰레드 / HTTP API / SSR / CSR 등 간단한 개념 * 웹 애플리케이션 서버(WAS) 웹 서버는 정적 리소스를, WAS(웹 애플리케이션 서버)는 애플리케이션 로직을 수행한다. 물론 웹 애플리케이션 서버에서도 웹 서버의 기능을 제공하기에 둘의 경계는 모호하다. 하지만 애플리케이션 코드를 실행하는데 특화되어 있는 것이 WAS. 웹 시스템은 최소한으로는 WAS와 DB로 구성되어있다. 이때 WAS에 많은 역할이 부여되어 과부하될 우려가 있어, 웹 서버를 따로 두어 정적 리소스를 처리하게끔! 만약 동적인 처리가 필요하다 -> 웹 서버가 WAS에 요청 위임 이렇게 웹 시스템을 구성하면 WAS나 DB에 장애가 나도 웹 서버가 오류화면을 제공할 수 있다. ..