Dispatcher Servlet 이란

servlet container 에서 http 프로토콜을 통해 들어오는 모든 요청을 프레젠테이션 계층의 제일앞에 두어

중앙집중식으로 처리해주는 프론트 컨트롤러이다.

Q) Front Controller(프론트 컨트롤러)란?

Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 

처리해주는 컨트롤러인데, MVC 구조에서 함께 사용되는 패턴이다.

그래서 공통처리 작업을 Dispatcher 서블릿이 처리한 후, 적절한 세부 컨트롤러로 작업을 위임해준다.

물론 Dispatcher Servlet이 처리하는 url 패턴을 지정해주어야 하는데 일반적으로 /*.do와 같이 /로 시작하며

.do로 끝나는 url 패턴에 대해서 처리하라고 지정해준다.

장점은 뭘까?

스프링의 MVC는 디스패처 서블릿이 등장함에 따라 web.xml의 역할을 상당히 축소를 시켜주었다.

기존에는 모든 서블릿에 대해 url 매핑을 활용하기 위해 web.xml에 모두 등록해주어야 했지만, 디스패처 서블릿이

해당 앱으로 들어오는 모든 요청을 핸들링 해주면서 작업을 상당히 편리하게 만들어 주었다.

그리고 이 디스패처 서블릿을 사용하면 @MVC 역시 사용할 수 있게 되어 좋다.

디스패처 서블릿의 기능처리 순서를 그리면 아래와 같다.

정리하자면 클라이언트가 정보를 요청하면 디스패처 서블릿에서 해당 요청을 매핑한 컨트롤러를 검색한다.

그리고 알맞은 컨트롤러를 찾아 view이름을 디스패처 서블릿에게 다시 알려준다.

그리고 디스패처 서블릿은 받은 view이름을 토대로 알맞게 찾아가서 viewResolver에게 넘겨준다.

viewResolver는 받은 정보를 통해 처리를 하고 처리결과를 View에 넘겨준다.

View는 처리결과가 포함된 view를 디스패처 서블릿에 다시 전달한다.

마지막으로 최종결과를 클라이언트에게 던져주고 끝이난다.

기본형 변수

boolean, char, byte, short, int, long, float, double 등

실제 연산에 사용되는 것은 모두 기본형 변수이다.

참조형 변수

기본형 8가지를 제외한 나머지 타입

참조형 변수를 선언할 때는 변수의 타입으로 클래스의 이름을 사용하므로 클래스의 이름이 참조형 변수의 타입이 된다.

Date today = new Date();

변수의 타입으로 클래스의 이름을 사용하므로 클래스의 이름이 참조형 변수의 타입이 된다.

Date 클래스 타입의 참조형 변수 today를 선언한 것이다.

참조형 변수는 null 또는 주소를 값으로 갖는다.

Date today = new Date(); 에서 today는 생성된 Date 객체의 주소값을 갖는다.

그렇다면 참조형 변수와 참조는 같은것일까?

다른것이다.

참조는 참조형 변수가 아닌 참조값(해쉬코드)이다.

예를들면 Car carVal = new Car(); 의 경우 new가 반환한 참조는 new Car(); 의 반환값(주소값)이고,

참조형 변수는 바로 carVal 이다.

아파치란 것은 소프트웨어 단체 이름이다.

그리고 우리가 흔히 부르는 아파치 서버라는 것은 이 재단에서 후원하는 오픈소스 커뮤니티에서 만든 http 웹서버를

지칭하는 말이다. (아파치 프로젝트는 웹서버 외에도 여러가지 프로젝트를 진행하고 있다)

클라이언트가 get, post, delete 등등의 메소드를 이용하여 요청을 하면 이 프로그램이 어떠한 기능을 돌려주는

기능을 한다. 아파치는 웹서버다.

tomcat은 흔히 WAS라고 말한다.

WAS는 웹서버와 웹 컨테이너의 결합으로 다양한 기능을 컨테이너에 구현하여 다양한 역할을 수행할 수 있는

서버를 말한다. 클라이언트의 요청이 있을 때 내부의 프로그램을 통해 결과를 만들어내고 이것을 다시 클라이언트에

전달해주는 역할을 하는 것이 바로 웹 컨테이너이다.

앞에서 본 아파치 웹서버와 차이는 이 컨테이너 기능이 있냐 없냐의 차이다. 이게 큰 차이점이라고 생각한다.

WAS역시 웹서버로서 역할을 수행할수 있기에 둘이 너무 헷갈린다.

위 그림에서 알수있듯 WAS만 쓰면되지 않냐 라는 질문에 반박할수 있게 된다.

목적이 달라서 WAS만 사용하면 안된다.

웹서버는 정적인 데이터를 처리하는 서버이다. 이미지나 단순 html 파일과 같은 리소스를 제공하는 서버는

웹서버를 통하면 WAS를 이용하는 것보다 훨씬 빠르고 안정적이다.

WAS는 동적인 데이터를 처리하는 서버이다. DB와 연결되어 데이터를 주고받거나 프로그램으로 데이터 조작이 필요한

경우에는 WAS 활용해야한다.

이때 DB가 왜 동적이냐?

DB는 항상 변하니까.

java 진영에서 말하는 WAS는 j2ee spec을 지원하는 것을 말한다.

원래 모든 스펙을 지원하면 WAS라고 구분했었고

servlet, jsp spec을 지원하면 Servlet Container라고 구분을 했었다.

<■ J2EE란?
J2EE는 자바 기술로 기업환경의 어플리케이션을 만드는데 필요한 스펙들을 모아둔 스펙 집합이다.>

그런데, j2ee spec의 핵심인 EJB의 인기가 식고 SPRING이 그 영역을 대체하면서

servlet, jsp spec을 지원하면 그냥 WAS라고 하고 있다.

엄밀하게 말하면, WAS와 Servlet Container를 구분하는게 맞다.

tomcat을 내장한 WAS가 여럿 있기 때문에 굳이 J2EE의 기술(EJB)을 쓰지 않는다면 tomcat으로 개발한 뒤

WAS에 올려도 거의 다 잘돌아간다고 한다.

쉽게 말해 정확한 의미의 WAS는 아니기도 하고, 포괄적인 의미의 WAS는 맞기도 하다.

Plain Old Java Object 의 줄임말이다.

직역하면 오래된 방식의 간단한 자바 객체 이다.

다른 개념 다 버리고 POJO = Java Beans .

여기서 Java Beans는 Sun의 Java Beans나 EJB의 Bean을 뜻하는것이 아닌

순.수.하게 setter, getter 메소드로 이루어진 Value Object성의 Bean을 말한다.

그럼 왜 POJO를 지향해야 할까?

특정 기술과 환경에 종속되어 의존하게 된 자바 코드는 가독성이 떨어져 유지보수에 어려움이 있다.

또, 특정 기술의 클래스를 상속받거나, 직접 의존하게 되어 확장성이 매우 떨어지는 단점이 있다.

이 말은 객체지향의 화신인 자바가 객체지향 설계의 장점들을 잃어버리게 된다는 말이다.

그래서 POJO라는 개념이 등장했다.

토비의 스프링에 이렇게 나와있다.

진정한 특정 기술규약과 환경에 종속이 안되면 모두 POJO냐?....

진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용 될수 있는

방식으로 설계된 객체를 말한다....라고.

어렵군...

EJB는 Enterprise Java Beans 의 줄임말이다.

EJB는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다.

쉽게 말해서, 효율적으로 서버를 관리하고 프로그램 관련 문제를 처리해줌으로서 업무 효율성을 증대시켜주는

프로그램이다.

그러나 사용하기도 어렵고 장비도 좋아야 사용할수 있다.

그리고 WAS 종류에 따라 다르기 때문에 사용이 힘든 단점이 있다.

이 단점을 커버해서 만든것이 바로 SPRING이다.

DBMS에서 데이터를 다루는 논리적인 작업의 단위.

게시글 등록을 누르면 등록이 되고 글 리스트로 돌아간다.

그럼 insert후 바로 select가 실행된다는 뜻인데 이때는 트랜잭션이 1개다. 2개가 아니다. 

트랜잭션은 데이터 처리에 있어서 필요한 일련의 과정이 전부 정상적으로 처리되거나 또는 하나라도 오류가 발생할 경우 Rollback 기능을 통해 전부 미처리 하는 경우에 사용한다.

- Advice : 언제 공통 관심 기능을 핵심 로직에 적용할 지를 정의하고 있다. 메서드를 호출하기 전/후에 공통 기능을 적용한다는 것을 정의.

- Weaving : Advice를 핵심 로직 코드에 적용하는 것을 말한다.

- Jointpoint : Advice를 적용 가능한 지점을 의미한다. 메서드 호출, 필드 값 변경 등이 Jointpoint 에 해당.

- Pointcut : Jointpoint 의 부분 집합으로 실제로 Advice가 적용되는 Jointpoint 를 나타낸다. 스프링에서는 정규표현식이나 AspectJ 문법을 이용하여 정의.

- Aspect : 여러 객체에 공통으로 적용되는 기능을 Aspect라고 한다. 트랜잭션이나 보안 등이 Aspect의 좋은 예.