Spring 복습 : 동작 흐름

강정우·2022년 9월 24일

spring

목록 보기

5/27

현재 우리는 Spring MVC templet을 기반으로 개발중이다. 밑은 Spring의 기본 동작 흐름이다.
하지만 시작하기 앞서 항상 2가지는 확인하고 가자 1. mySQL의 bat파일을 실행했는가? 2. DataBase tab에서 mysql과 eclipse를 연결해주었는가?

spring 기본 동작 흐름

1. Dispatcher Servlet

서버에서 페이지를 받을 때 Request 즉, 요청이 가장 먼저 일어난다.
모든 웹은 url을 통해서 요청이 일어난다.
이때 request객체가 url을 요청 하면 ~~.do 라고 뜨는데 이때 모든 요청을 Dispatcher Servlet 이 받는다. 즉, 예전의 front controller가 Dispatcher Servlet 이다.
하지만 우리는 Dispatcher Servlet을 만든적이 없다. 그럼 누가 만들어주냐? 바로 web.xml 이 만들어준다. 여기에 적으면 spring 특정 객체 memory 영역에 올라가 내가 따로 손대지 않아도 알아서 만들어준다.

2. Mapper

그렇다면 Dispatcher Servlet 이 실질적인 일을하냐? 그것은 아니다. 그저 안내하는 역할만 한다. 실제로 일을 하는 녀석은 바로
@Controller이라고도 불리고 POJO 라고도 불리는 plan old java object 녀석들이 실제로 동작을 하는 녀석들이다. 그럼 이 dispatcher servlet과 실제로 일하는 POJO가 어떻게 연결되나? 바로 mapper가 해준다. 다만 조건이 있다.

해당 POJO에 request mapping이 되어있어야한다.
이게 일을 하는 @Controller라고 명시되어있어야 한다.

하지만 여기서 의문점이 생길건데 어떻게 이렇게 많은 파일에서 annotation 을 바로 찾을 수 있을까?
바로 servlet-context.xml의 이 친구가 여기에서만 찾으라고 명시해 두었기 때문이다. 위의 코드를 해석하자면
무엇을 하냐 : conponent 객체들을 scan 해라
어디서 : base-package를 기반으로
어떤 것을 : @controller가 적혀있는 녀석들을

3. Adapter

그런데 이 둘의 파일을 찾아도 바로 실행할 수 없다 왜? dispatcher servlet 과 POJO 는 서로 다른 파일이기 때문이다. 그렇다면 이 둘을 연결해주는 매개체가 필요하다. 그것이 바로 adapter 이다.
즉, Mapper 은 그저 POJO 파일을 찾는 역할만 하고 POJO 와 dispatcher servlet 연결하여 실행하는 녀셕이 바로 adapter 이다.

4-1. Mybatis

이제 POJO 가 DB에 접근할 때를 알아보자 이때 필요한 녀석이 바로 mybaits이다. 이녀석이 java와 sql분리를 실현할 수 있도록 도와주는 녀석이다.
이때 DBCP 라는 개념이 등장하는데 자세한 부분은 앞서 포스팅한 부분을 읽어보면 된다. 이 DBCP를 구동하기위해 필요한 lib중 가장 기본적인 녀석이 hikariCP 인데 이녀석 또한 mybatis 안에 포함되어 구동된다.

4-2. hikariCP

hikariCP의 내부에는 JDBC가 있어 conn을 알아서 만들어준다. 또한 spring에서는 <tag>로 만들어진것들은 모두 spring memory에 올라가서 언제는 쓰일 수 있게 한다.
그럼 JDBC의 연결에 필요한 녀석들의 정보는 어딨냐? 바로 root-context.xml 안에 이녀석에게 있다. config == conn을 연결할 수 있는 정보이다. 그래서 datasource 객체를 만들 때 필요한 정보들을 config id에 담아서 보낸 것이다. 그래서 2번까지가 JDBC의 conn 생성이라 생각하면 된다. 그리고 실제로 DB에 접속하는 JDBC의 DAO의 역할은 하는 녀석들은 session factory에 있다.

4-3. Mapper.java (Interface)

2번의 Mapper와는 다른 일을 수행하는 녀석들로 어떤 차이가 있냐 어떠한 2객체를 연결해준다는 임무는 같지만
4-3의 Mapper는 실제 일을 수행하는 POJO 와 Sql문을 적는 Mapper.xml 이 둘을 이어주는 interface이다.

그리고 이 Mapper.xml 은 최상단에 Mapper interface를 적어줌으로써 mybatis가 알아서 Mapper.java, Mapper.xml을 이어준다.
하지만 여기서 또 의문점이 생길건데 어떻게 이렇게 많은 파일에서 Mapper.xml 을 바로 찾을 수 있을까?
바로 여기서 명시하기 때문이다. xml을 scan해라 그럼 이제 hikariCP 가 알아서 연결해준다.

5. POJO, DI개념

우리는 그동안 class와 객체를 direct로 연결하여 수정소요가 매우 높았다.
이게 무슨말이냐 하면 만약 당신이 VO class를 바꿨다면 아마 다른 코드에 빨간줄이 미친듯이 생겼을 것이다. 이를 "결합도가 높다"라고 한다. 하지만 이것을 interface로 만들어 spring memory 영역에 올림으로써 편하게 갖다 쓸 수 있도록 만들었다. 즉, "겹합도를 낮춰준다."라는 뜻이다.
하지만 이 interface를 구현(implement)하여 써야되는데 이것을 누가 해주냐? 바로 POJO에 있는 이녀석 @Autowired가 해준다. 이는 memory에 interface를 올려놓고 주입받아서 쓰는 법으로 의존성은 높히고 결합도를 낮추는 방법 즉, Dependency Injection DI라고 한다. 이는 Spring에서 아주 중요한 개념이다.
그렇다면 이제 POJO(controller)는 할 일이 view name만 넘겨주면 된다.
또한 POZO 에서는 매개변수를 쓰기만 하면 의존성 주입으로 받아올 수 있다.

@RequestMapping("/boardInsert.do")
public String boardInsert( Board board ) {			<= 의존성 주입부분
    mapper.boardInsert(board);
    return "redirect:/boardList.do";
}

@RequestMapping("/boardList.do")
public String boardList( Model model ) {			<= 의존성 주입부분
	List<Board> list = mapper.boardList();
    model.addAttribute("list", list);
    return "boardList";
}