MVC Pattern, Session, Cookie

JSP를 이용하여 구성할 수 있는 Web Application Architecture는 크게 model1과 model2 로 나뉜다.

Model1 : client의 요청에 대한 Logic처리와 response page(view)에 대한 처리를 모두 함
Model2 : 화면에 보이는 부분만 처리 (= MVC패턴을 웹 개발에 도입한 구조 )

 

Model1

• view와 logic을 JSP페이지 하나에서 처리하는 구조
• 장점 
  • 구조가 단순하고 직관적, 배우기 쉽다
  • 개발 시간이 비교적 짧기 때문에 개발 비용이 감소
• 단점
  • view코드와 로직처리를 위한 java코드가 섞여 있어서 JSP코드 자체가 복잡해진다
  • JSP코드에 BE와 FE가 혼재되어 분업이 힘들어짐
  • 프로젝트 규모가 커지게 되면 코드가 복잡해져 유지보수가 어려움
  • 확장성(신기술 도입, framework)이 나쁘다

Model2

• client 요청에 대한 처리는 servlet
• logic처리는 java class(Service, Dao)
• response page는 JSP가 담당

 

• Model
  • Logic(Business & DB Logic)을 처리하는 모든 것
  • Service, Dao, Java Beans, DTO
  • controller로 부터 넘어온 데이터를 이용하여 이를 수행하고 그에 대한 결과를 다시 controller에게 return 한다.
• View
  • 모든 화면처리 담당. 
  • Client의 요청에 대한 결과 뿐 아니라 controller에 요청을 보내는 화면단도 jsp에서 처리한다.
  • Logic처리를 위한 자바 코드는 사라지고 결과 출력을 위한 자바 코드만 존재
  • JSP
• Controller
  • Servlet
  • Client의 요청을 분석하여 Logic처리를 위한 model단을 호출한다.
  • return 받은 결과 data를 필요에 따라 request, session등에 저장하고,
  • redirect 또는 forward 방식으로 jsp(view) page 를 이용하여 출력한다.

controller👉service 👉dao 순서를 지켜줘야 함
controller는 항상service만 호출!

 

• 장점
  • 출력을 위한 view(html) 코드와 로직 처리를 위한 java코드가 분리 되었기 때문에 jsp는 model1에 비해 코드가 복잡하지 않다.
  • 화면단과 Logic단이 분리 되었기에 분업이 용이해 졌다.
  • 기능에 따라 code가 분리 되었기 때문에 유지 보수가 쉬워졌다.
  • 확장성이 뛰어나다
• 단점
  • 구조가 복잡하여 초기 진입이 어렵다
  • 개발 시간의 증가로 개발 비용 증가

 

Model2가 Model1보다 항상 좋은가?
👉 유지보수가 별로 필요없는 경우 Model1이 유리하다

 

http protocol의 특징

응답 후 연결을 해제한다 (stateless)

지속적인 연결로 인한 자원낭비를 줄이기 위해 연결을 해제함.

client와 server가 연결 상태를 유지해야 하는 경우 문제 발생(로그인 정보 등)

client단위로 상태 정보를 유지해야 하는 경우 Cookie와 Session이 사용됨

 

HTTP protocol의 특징(약점)을 보완하기 위해 Cookie와 Session을 사용

Cookie

• 100% 클라이언트 기술
  • 서버에서 사용자의 컴퓨터에 저장하는 정보파일
  • 사용자가 별도의 요청을 하지 않아도 브라우저는 request시 Request Header를 넣어 자동으로 서버에 전송한다.
  • Browser마다 저장되는 쿠키가 다름(서버에선 Browser가 다르면 다른 사용자로 인식)
  • Browser가 종료되어도 Cookie의 만료 기간이 남아있다면 Client는 계속 보관
  • Cookie의 key와 value는 둘 다 String이어아 함!
• 삭제 메소드(delete와 같은)가 없다 👉 setMaxAge 로 관리

cookie.setMaxAge(0); // cookie 삭제

• 생성된 cookie를 client로 전송

response.addCookie(cookie);

• Cookie를 수정하는 방법
  • 바꾸고자 하는 쿠키의 key값을 가지는 쿠키를 새로 만들어 주면 됨. (단, setMaxAge는 해줘야 함. 설정해주지 않으면 Browser 종료 시 만료된)

 

Session

• 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라 함.
• WAS의 memory에 Object 형태로 저장 (하드에 저장되지 않음)
• memory가 허용하는 용량까지 제한 없이 저장 가능
• 브라우저를 닫거나, 서버에서 세션을 삭제 했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
• 저장 데이터에 제한이 없다.
• Browser당 하나의 JSESSIONID를 할당 받

동작순서
1. 클라이언트가 페이지를 요청.
2. 서버는 접근한 클라이언트의 request header필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인.
3. session-id가 존재하지 않는다면, 서버는 session-id를 생성해 클라이언트에게 돌려준다.
4. 서버에서 클라이언트로 돌려준 session-id는 쿠키를 사용해 브라우저에 저장. 쿠키이름 : JSESSIONID
5. 클라이언는 재접속 시, JSESSIONID(쿠키)를 이용해서 session-id 값을 서버에 전달.

👉 session은 서버기술 이지만 클라이언트에 의존적이다.

 

• session 생성 (new가 아니다!)

HttpSession session = request.getSession(); // 없으면 만들어서 반환 (default가 true)
HttpSession session = request.getSession(false); // 없으면 null 반환

• 값 저장

session.setAttribute(String name, Object value);

• 값 얻기

Object obj = session.getAttribute(String name);

• 값 제거

session.removeAttribute(String name); // 특정 이름의 속성제거
session.invalidate(); // binding되어 있는 모든 속성 제거

• 생성시간

long ct = session.getCreationTime();

• 마지막 접근 시간

long lat = session.getLastAccessedTime();

 

⭐ 세션 타임아웃(유효시간)은 마지막 connection이후 카운팅 된다. (생성된 이후 카운팅이 아님)
⭐ 만료시간은 web.xml에서 설정함.