JSP_국비_DAY55

Buisness Logic : 사용자의 요청과 함께 전달된 정보를 가공및 산출하는 부분 

Presentation Logic : 가공되어 산출된 정보를 디자인하여 사용자에게 표출하는 부분

 

Model 1 -> 비즈니스 로직과, 프레젠테이션 로직을 한 문서에 저장하는 웹 개발 패턴

Model 2 -> 비즈니스 로직은 개발자가 Servlet으로 프레젠테이션 로직은 JSP가 담당하며, 각각의 역할을 분할하여 수행한다.

MVC(Model View Controller) -> 위의 두 모델의 단점을 보완하고자 등장한 디자인 패턴. 컨트롤러가 사용자의 요청을 받고, 모델과 통신하면서 모델이 가공한 데이터를 받으면 뷰에게 전달하여 뷰가 출력하면서 사용자의 요청에 응답한다.

 

JSP(Java Server Page) 

ㄴ> jsp는 servlet이다. 결론적으로 출력되는 결과는 같다. 

ㄴ> 개발자가 작성할 때는 html코드이지만, 실행이 될 때, Tomcat이 servlet으로 변환하하고, 컴파일 하여 실행한다.

ㄴ> 컨테이너에는 JSP파일이 들어올 수 없다. 즉, 실행시에는 JSP파일은 존재하지 않는다. 이미 서블릿 파일로 바뀌어서 컨테이너에 로딩되었기 때문이다.  

 

Servlet은 베이스가 자바이므로, 자바코드 안에서 html을 작성하는 구조이다.

내용이 변경되면 서버를 restart하는 것이 맞다. 하지만 reloadable=true속성을 주면 재시작을 하지 않아도 잠시 기다리면, Tomcat이 컨테이너에 있던 서블릿(변경 이전)을 삭제하고, 새로운 서블릿(변경 이후)을 적재한다. 

JSP는 베이스가 html이고, 자바코드안에 html code를 삽입한다. 서블릿에서 html코드를 작성하면 PrintWriter를 받아서 직접 태그와 내용을 작성해야 했지만, JSP로 html코드를 작성하고 실행을 하면 JSP가 서블릿으로 변환되는 과정에서 JSP가 대신 html코드를 자바코드로 작성해서 전송해준다. 내용이 변경되면 저장하고 refresh(F5)하면 된다.

이클립스에서 Project Explorer에서 보이는 것은 편집소스이다.

컴파일된 실행소스는 워크스페이스의 메타데이터 파일의 끝에 존재한다. 경로는 아래 첨부하겠다.

C:\Work\WebStudy\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\2022_0518_JSPTest\org\apache\jsp

필자는 Test.jsp코드를 작성했다. 위의 경로에 들어가보면 Test_jsp.java와 Test_jsp.class두 개의 파일이 존재하는데, 자바 파일은 내가 작성한 JSP파일이 Servlet으로 변형된 형태이고, 클래스파일은 변경된 자바 파일이 컴파일된 파일이다.

JSP 구조 

• <%@ ~~ %> : JSP Header -> Encoding, import, Error Code
• <%!  선언부(변수 또는 메소드)  %> 
  • jsp에서 작성한 html코드는 _jspService()메소드 외부에 기록된다. 
• <% ~~ %> : Scriptlet _jspService()메소드 내부에 기록된다. html어느 위치에서든지 scriptlet을 사용하면 자바에 대한 모든 코드를 사용할 수 있다.
• <%=변수 %> : 어디서든 작성된 내용을 출력할 수 있다(표현식)

 

JSP 인클루드 방식 (두가지 방식 모두 도출되는 결과는 동일하다.)

1. Directive Tag : <%@include %>
   1. A.jsp내에 B.jsp을 합쳐서 1개의 서블릿으로 관리 및 처리한다.
2. JSP Action Tag : <jsp:include />
   1. A.jsp내에 B.jsp를 합쳐서 관리한다. 단, 1번과는 다르게 2개의 독립적인 서블릿이 생긴다. 

 

Model1 Architecture

모든 클라이언트의 요청과 응답을 JSP가 담당하는 구조이다. 

단순한 페이지 작성으로 쉽게 구현이 가능하다. 

소형 프로젝트에 적합하다. 

단, 웹 애플리케이션이 복잡해지면 유지보수가 힘들어진다. 

 

Model2 Architecture

클라이언트의 요청처리와 응답처리, 비즈니스 로직 처리하는 부분을 모듈화시킨 구조이다.

사용자가 요청하는 서비스에 대해 서비스 객체가 1:1로 매칭이된다. 

사용자 요청을 서블릿(컨트롤러)이 받아서 DAO에게 요청해서 DB에서 데이터를 가져와 가공한 결과를 JSP(VIEW)에게 전달한다. 

JSP(VIEW)는 서블릿으로부터 받은 데이터를 디자인하여 사용자에게 응답처리한다.

처리작업의 분리로 인해 유지보수와 확장이 용이하다. 

개발자와 디자이너의 역할과 책임 구분이 명확해진다. 

각 컴포넌트의 재사용성이 높아진다. 

단, MVC구조에 대한 이해가 필요하며 개발자의 높은 skill이 요구된다.

 

MVC

전통적인 GUI 애플리케이션을 구현할 때 사용되는 디자인 패턴이다. 

사용자의 입력을 받아서 처리하고 결과를 사요자에게 다시 보여주는 형태의 설계기법이다. 

처리 작업의 분리로 인해 유지보수와 확장이 용이하다. 

각 컴포넌트의 재사용성이 높아진다. 

웹 애플리케이션을 구현할 때 일반적으로 많이 사용하는 패턴이다.

 

Model2와 MVC의 차이 

Model2는 각각의 요리를 만드는 요리사가 한 명씩 대기한다. (한명한명이 모두 컨트롤러다.) 대표로 주문을 받는 컨트롤러가 없다. 요리사는 하나의 요리(하나의 서비스에 대한 업무만 수행할 수 있다.)만을 할 수 있다. 요리사가 직접 주문을 받아서 손님의 주문에 따라 요리를 한다.(각각의 서비스객체가 직접 사용자의 요청을 받아서 작업한다. 서비스객체가 너무 많아서 메모리의 낭비가 발생할 수 있다.)

MVC는 요리사들이 주방(model=dao)에서 대기한다. 대표로 주문을 받는 사람(컨트롤러, 서블릿 하나로 구성)이 사용자의 주문(요청)을 받아서 주방의 요리사에게 전달(서비스 객체를 호출)한다. 대표로 주문을 받는 사람은 요리사(서비스 객체)에게 요리하도록 지시한다. 음식이 나오면(지시에 대한 결과물이 나오면) 컨트롤러가 서빙알바(view, jsp)에게 전달하고, 서빙알바는 손님에게 음식을 가져다 준다.(응답처리) 

 

EL(Expression Language) <html(x) jsp에서만 사용가능>

JSP에서 자바 scripting(=scriptlet) 대신에 데이터를 출력하기 위한 기능이 확장된 표현언어이다.

변수와 연산자를 포함할 수 있다. 

JSP의 scope에 저장된 속성 및 자바 빈즈 속성도 EL의 변수로 사용 가능하다. 

EL자체의 내장 객체가 제공된다. 

표현식에는 숫자, 문자열, boolean값과 null도 포함할 수 있다.

방법 : ${ 표현식 }

 

 

[아주 중요] -> 객체의 생존주기를 결정하는 영역의 범위

한 사진에 담기 위해 글씨가 많이 작지만,, 확대해보면 보일 것이다. 자세한 내용은 이미지 밑에 설명하겠다.

 

 

1. pageContext

• 브라우저에서 사용자의 요청이 들어오면, Tomcat이 요청을 처리해줄 서블릿에 request와 response객체를 생성한다.
• 이때 각각의 서블릿은 위의 네모박스 처럼 자신만의 공간을 사용할 수 있는데 이 영역이 pageContext이다. 
• 이 영역에 접근하기 위해 사용하는 내장객체 또한 pageContext이다. 
• 뒤이어 설명할 request와 session영역보다 이용가능한 영역은 작지만, 해당 서블릿이 소멸되는 순간(서블릿의 소스파일이 변경되거나 삭제된 경우) 영역이 사라기지 때문에 생존주기가 비교적 더 길다. 

2. request

• 다시 처음으로 돌아와보자. 사용자의 요청이 발생하면 Tomcat이 요청을 처리해줄 서블릿에 request와 response객체를 생성해준다고 했다. 이때 servlet1이 servlet2에게 forward를 하면, servlet1이 가지고 있던 request와 response객체를 servlet2와 공유한다.
• 이런 경우, servlet1이 사용자의 요청을 받고, servlet2가 사용자에게 응답을 처리하는데, 이때 servlet1이 컨트롤러의 역할을 하고, servlet2가 뷰의 역할을 수행한 것이다. 
• 기본적으로 객체의 생존주기는 요청을 받은 순간 부터 응답을 처리하는 순간까지이다. 
• 이렇게 forward를 하게 되면 공유된 동일한 객체가 servlet1, 2의 개인 영역인 pageContext를 모두 접근할 수 있다.  
• 그리하여 forward가 발생하면 Tomcat이 따로 request사용공간을 할당해주고, 공유된 객체는 이 공간에 저장된다. 
• 결론적으로 forward가 되면 forward로 연결된 모든 서블릿의 pageContext에 접근할 수 있다. 
• 물론 두 개이상의 서블릿을 forward할 수 있지만, 복잡해서 많이 사용하지 않는다고 한다. 

3. Session 

• 사용자가 서버에 처음 접속할 때, 서버에서 사용자에게 고유 id번호를 주고, 이 번호를 브라우저 내부 쿠키에 저장한다. 사용자는 모든 서블릿을 사용할 수 있다. 
• session객체에서는 session의 정보를 저장할 유효시간과 id값을 기억한다. 
• 유효시간은 사용자가 접속하여 아무런 행위도 하지 않을 때의 시간이며, 사용자가 접속해서 서블릿을 이동하면 유효시간은 다시 30분으로 갱신된다. 
• 사용자가 브라우저를 닫는 등의 접속을 끊으면 사용자에게 할당한 session을 삭제하고, 다시 들어오면 새로 생성해서 할당한다. 
• 사용자는 서버에게 할당받은 id번호를 가지고 모든 서블릿을 돌아다닐 수 있으며 각 서블릿에서는 request.getSession()메서드를 사용하여 접속한 사용자의 정보를 알아낸다.

4. Application

• 서버에 접속한 모든 유저가 사용할 수 있는 공간이다.
• 서버가 실행될 때, 생성되고, 서버가 종료될 때, 소멸된다.