20211207 스프링에 대한 전반적인 이해

DUUUPPAAN·2021년 12월 7일
0

Spring_Framework

목록 보기
2/19

·스프링을 다운받고

-스프링 프레임워크를 사용하여 프로젝트를 진행할 환경을 전부 만들었다. 그런데, 사실 다운은 받았지만, 기존과 어떻게 달라졌는지 구체적으로 알지는 못했다. 그냥 기존의 요청에 대한 처리를 분할해서 처리해준다 정도로만 알고 있었고 교수님이 이 파일 저 파일 계속 왔다갔다 설명해주셨지만, 메모장에도 적으면서 교수님을 따라갔지만, 사실 이해가 안되는 부분이 상당했다.

-그래서 정말 힘든 오전이었다. 교수님의 말이 제대로 이해가 되지 않았다. 나만 그런게 아니라, 아직 큰 틀에서의 그림이 그려지지 않은 사람들이 수두룩했다. 나는 오늘 비대면으로 수업을 진행하려고 했는데, 오전 수업이 정말 이해가가지 않아서 점심때 학원으로 바로 출발했다. 점심을 편의점 김밥으로 떼웠지만 그게 대수랴 이해하는 것이 더 중요했다.

-사실 오후 수업까지도 크게 전반적인 내용을 이해했다고 하기는 어려웠다. 그러던 중, 교수님이 내게 질문을 하셨고, 이해가 안되는 부분을 짚어달라는 질문에 나는 이렇게 질문을 드렸다.

"클라이언트의 요청에 dispatcher가 어노테이션으로 맵핑된 컨트롤러를 찾아서 만약 DB연동이 필요하다면 service를 호출하고 service에서 dao를 통해 db의 정보를 가져와서 다시 결과를 디스패쳐에게 보내고 이런 일련의 과정들이 그려지기는 한다. 그런데 대체 root-context.xml과 servlet-context.xml이 어느 시점에 구동되고 어느 시점에 참조를 해야하는지를 모르겠습니다."

-사실 모든 절차가 이해가 된 지금 시점에서 저 질문이 얼마나 바보같은지 알고 있지만, 그 당시에는 정말 이해가 가지 않았다. 나중에 물어보니 다른 사람들도 비슷한 의문점이 있긴 했던 것 같다. 그래서 교수님이 아예 WAS를 실행시키고 어떻게 진행이 되는지를 한 번 설명해주셨다. 그리고 해당 부분을 정리하니까 굉장히 일목요연하게 정리가 된 느낌이었다.

-스프링 MVC모델
-MVC 모델은 각각 model, view, controller의 약자로 기존의 jsp와는 다르게 화면으로 보여주는 부분과 보여지지 않는 부분의 로직처리를 나눠서 처리하는 모델이다. 여기서 controller는 그럼 무슨 역할인가하는 의문점이 생기는데, 요청에 대한 처리를 controller가 분배해준다고 생각하면 된다.

-그렇다면 굳이 왜 이런 분리를 해야하는 것일까? 처음엔 이 의문이 강했다. 기존보다 더 복잡해지는 느낌인데 굳이 왜 이렇게 해야하는 것인지 의문이 들었다. 답은 간단했다. 바로 유지 및 보수가 용이하고 분업이 쉬워지기 때문이다. 예를 들면, 화면을 담당하는 사람은 보여지는 화면에만 신경쓰면 된다. 요청에 대한 결과가 해당 jsp를 가리키면 보여줄 화면에만 신경쓰면 되지, 해당 jsp의 결과를 어떻게 얻어왔는지는 신경쓸 필요가 없다. 반대의 경우도 마찬가지이다. 이렇게 되면 특정 부분에서 문제가 생겼을 때 보수하기도 편하고, 유지도 매우 편리해진다. 뿐만 아니라, JDBC드라이버에 접속하는데 Connection 객체, PreparedStatement객체, ResultSet객체를 얻어올 필요 없이 MyBatis를 활용해서 그냥 기존의 쿼리문을 사용할 수도 있어서 DB에서 정보를 얻어오는 것도 굉장히 편리해진다.

-오늘 수업이 끝나고 내가 직접 정리한 WAS가 켜지고 나서의 일련의 과정에 대한 부분이다.

스프링 프레임워크에 대한 이해
우선 was, 톰캣을 실행했을때의 과정
1. 톰캣의 환경설정은 톰캣폴더의 conf
2. server.xml에서 설정한 포트번호 8088, 8088을 찍으면 내가 호출되도록 하겠다는 설정
3. server.xml에서 호스트 이름으로 들어오면 appBase를 타줌.
4. appBase의 값이 ""이기 때문에, 톰캣에서 정의되어 있는 CATALINA폴더에 해당 호스트이름으로 된 폴더가 생성됨
5. 해당 폴더의 ROOT.xml을 읽어오는데, 내용 중에 docBase가 있고 경로가 써있음
6. 해당 경로가 바로 베이스가 되는 폴더임. 현재는 C:\project\webapps\hiboard\src\main\webapp 이곳으로 되어있음
7. 이제부터 스프링에 대한 설정도 시작함. 스프링은 기본적으로 webapp밑에 WEB-INF 폴더의 web.xml을 기준으로 환경설정을 시작
8. web.xml을 읽으면 root-context.xml을 읽어오게 됨
9. root-context.xml에서 env를 읽어옴 env에는 db 접속 정보 등에 대한 환경 변수가 있음. 히카리 데이터 베이스나, 데이터 풀에 대한 설정도 있지만, 아직은 설명해주지 않으심
10. userDao.java와 userDao.xml을 연결시켜주는 맵핑작업을 함. 해당 둘을 연결시켜서 템플릿을 만듬
11. 마지막으로 userService와 같은 서비스 파일들이 모여있는 패키지를 메모리에 올림.  
	서비스는 userDao처럼 dao 객체를 사용해서 쿼리에 대한 메소드를 실행하고 결과를 리턴하는 클래스임
	전에 했던 <%  %>부분의 userDao객체를 생성해서 쿼리문을 날리는 것과 비슷함. 
	단, 이때, userDao는 인터페이스임. 추상메소드만 정의되어 있음. 빈 껍데기만 있음
12. 리스너와 필터 등을 또 정의하는데, 필터는 인코딩 타입 부분에 대한 영역인 것 같음
13. 리스너는 읽어오는 역할을 하는 객체
14. 디스패쳐에 대한 설정을 함. 이 때, servlet-context.xml을 불러옴.
15. servlet-context.xml에서는 url 맵핑을 시작, 해당 경로로 이미지, 자바스크립트, 스타일 시트등의 디렉토리가 설정됨.
16. 인터셉터에 대한 부분 정의해줌.
17. View Resolver에 대한 것도 정의해줌. View Resolver는 요청한 리퀘스트에 대한 결과를 가지고 보여줄 view를 찾아주는 역할을 함.
18. 이제 지금까지 설정했던 모든 내용을 메모리에 올리고 WAS가 정상적으로 실행됨.
19. hiboard.icia.co.kr:8088로 접속을 하게 되면, 기존에는 WAS가 docBase인 webapp를 가리킴
	->그리고 웰컴파일 리스트 중 index.jsp를 찾아감. 근데 해당 index.jsp가 해당 요청을 dispatcher로 넘겨버림
20. dispatcher는 해당 요청을 받고 어노테이션을 통해 컨트롤러를 찾아가게 되는데, 이 때 인터셉터가 요청을 가로챌 수 있지만, 미리 정의해놓은 servlet-context.xml파일에 보면 
	index.jsp는 인터셉터가 무시하도록 설정해놨음. 그래서 바로 어노테이션으로 해당하는 컨트롤러를 찾아감
21. IndexController에서 "/index"를 리턴함. 따로 DB를 연동할 필요가 없어서 따로 DAO쪽으로 가지 않음
22. 요청에 대한 응답을 받은 dispatcher는 리턴받은 결과를 View Resolver에게 전달
23. View Resolver는 미리 지정해놓은 prefix와 suffix를 응답으로 받은 "/index"와 조합해 해당 jsp의 경로를 찾아냄
24. 해당 경로를 dispatcher에게 알려주면 dispatcher가 최종적으로 클라이언트에게 응답을 해줌.

-여기서 컨트롤러가 따로 DB에 접속을 할 필요가 없었지만, 만약 DB에 접속해야 한다면, Controller가 해당하는 Service에게 작업을 넘긴다. Service는 (User 테이블의 정보를 가져온다는 가정하에 설명) 다시 userDao에 있는 userSelect메소드를 통해서 해당 쿼리의 결과를 얻어온다. 그러면 userDao에 가서 살펴봐야 하는데, userDao는 인터페이스다. 즉, 추상메소드로만 이루어져 있고 따로 오버라이딩해서 사용해야 한다. 그런데 따로 오버라이딩 된 부분이 없다. 왜일까? 바로 userDao.xml에서 해당 메소드를 오버라이딩 해주고 있기 때문이다. 사실 오버라이딩이 아니라 jstl+el 문법을 사용한 것이지만 오버라이딩으로 이해하면 편할 것 같다. 왜 userDao.xml에 정의하냐면, 쿼리문을 더 편하게, SQLdeveloper에서 쓴 것처럼 자바에서도 간단하게 사용하도록 해주는 것이다.실제로 userDao.xml을 열어보면 쿼리문이 sql.append() 등의 메소드 없이 태그 안에 그대로 들어가 있다. userDao.java와 userDao.xml은 root-context.xml에서 맵핑에 대한 부분을 정의해놨다. 그래서 두개가 매핑될 수 있는 것이다. 이제 서비스는 해당 쿼리의 결과를 컨트롤러에게 리턴하고 컨트롤러는 해당 결과를 통해 불러올 view의 이름을 리턴한다. 그리고 ViewResolver가 해당이름을 형식에 맞게 편집하여 경로를 찾아서 해당 경로의 해당 파일을 보여준게 되는 것이다.

-지금까지 한 일련의 설명을 너무나도 명확하게 잘 설명한 그림이 있어서 타 블로그에서 가져와봤다. 아래의 사진이 정말 오늘 수업의 시작과 끝이라고 해도 과언이 아니었고 이 그림을 여러번 보니까 조금 부족했던 부분도 쉽게 이해할 수 있었다. 내일부터는 조금 더 실전에 가까운 수업이 될 것 같다. 집중해서 들어야지!!! 우리팀의 첫 공식적인 회의가 있을 예정이다. 교수님까지 참여해서 하는 회의이니만큼 주제선정부터 다른 세세한 부분까지 어느정도 의견을 나눌 예정이기 때문에 잘 정리해서 가야겠다.


이미지 출처: http://server-engineer.tistory.com/253

profile
비전공자란 이름으로 새로운 길을 가려 하는 신입

0개의 댓글