Spring MVC 패턴의 구조 파악 4 (Controller 파트)

https://hwanii96.tistory.com/314

 

위의 글에서, Spring에서

 

DispatcherServlet 을 포함 해서,

Controller 인터페이스,

HandlerMapping 클래스,

ViewResolver 클래스

까지 전부 다 기본 제공 해주기 때문에,

 

DispatcherServlet-servlet.xml 내부에서 세팅 하는것을 정리 했다.

 

근데,

실제로 Spring 에서는 .xml 기능 설정 파일 내부의 코드가 길지 않고,

@ 어노테이션을 훨씬 더 많이 사용 한다.

왜 ?

가독성 측면에서 훨씬 유리 하므로 !

 

그래서, DispatcherServlet-servlet.xml 내부의 코드를 전부 지우고,

@ 어노테이션 방식으로 변경하는 작업을 해보려고 한다.

 

1.

@ 어노테이션 개념

 

https://hwanii96.tistory.com/309

스프링 컨테이너 어노테이션 메모

 

에서 확인 할 수 있다.

 

2.

DispatcherServlet-servlet.xml 내부 코드 확인 하기.

 

 

어노테이션 방식으로 객체화를 하기 위해, 기존에 작성 되어 있던,

<bean> 태그를 통한 객체화 라던지,

의존 주입을 위해 작성된 <property> 태그 라던지,

모두 제거된 모습 이다.

 

3.

@Controller

 

Spring 에서 @Controller 어노테이션은,

@Component 어노테이션을 상속 받은 어노테이션 이다.

 

@Controller 어노테이션을 사용하면,

더 이상,

Spring의 Controller 인터페이스를,

구현 하지 않겠다는 의미 이다.

 

이것이 의미하는 바는, 아래와 같다.

 

>>

@Controller 를 사용해서,

메서드와 메서드 시그니쳐 강제성이 부여 되지 않는다.

 

>>

@RequestMapping

특정 요청에 대해, Controller 객체를 찾아가는게 아니라,

메서드를 찾아간다.

 

어 ? 근데,

메서드와 메서드 시그니쳐 강제성이 부여 되지 않게 됬네 ?

 

즉, 메서드명, 리턴타입, 인자의 개수를 내 마음대로 작성 할 수 있네 ?

 

어 ? 그러면,

하나의 XxxController 클래스에,

두개 이상의 메서드가 존재 해도 되는거네 ?

의 결론이 나오게 된다.

 

왜 ?

메서드명을 더이상 인터페이스의 추상메서드명과 동일하게,

작성 하지 않아도 되니까 ~~

 

그래서,

유사한 코드 또는 관련된 애들끼리는,

XxxController 클래스에 몰아 넣고,

응집도를 높히고, 유지 보수를 용이 하게 할 수 있다.

 

이러한 방식은 장단점이 있어서, 상황에 맞게 잘 활용 하는게 중요 하다.

 

하지만, 보편적으로 이러한 형태의 구조를 실제로 많이 사용 한다.

 

4.

@Controller 어노테이션을 사용함으로써,

해당 자료형은 모두 객체화 되며,

XxxController.java POJO 클래스는 아래와 같이 코드가 변경 된다.

 

 

기존 코드는 아래와 같다.

 

 

Spring 에서 기본 제공 해주는 Controller 인터페이스를 구현 했으니까,

implements 키워드도 붙어 있고,

 

사용 하기 위해서, import도 했기 때문에,

POJO 클래스 내부의 코드가 무언가 많이 붙어있었는데,

 

상대적으로 간결해지게 된다 !

 

5.

@RequestMapping

 

HandlerMapping 클래스의 기능을 하는 @ 어노테이션 이다.

 

계속 헷갈려서 정리하는 메모.

 

@RequestMapping 어노테이션이 사용자의 요청값을 매핑하고,

해당하는 기능을 수행 하기 위해서, 메서드를 호출 하는데,

이 메서드를 호출 하기 위해서는, 당연하게도 해당 메서드를 지니고 있는 !

자료형 == 클래스를 객체화 해야한다.

 

그래서 @Controller 어노테이션이 반드시 선행 되어 있어야 한다.

그니까, 객체화가 되어 있어야 한다.

 

흐름 : https://hwanii96.tistory.com/311

 

HandlerMapping 이란 ?

사용자의 요청에 대한 Controller 자료형의 객체 반환을 수행 한다.

 

HashMap 으로 이루어져 있고,

사용자의 요청 == command == key 

가 키워드로 들어오면,

 

해당 요청 == command == key 에 대한,

value == 값 == Controller 자료형의 객체

 

를 get(key) 해서 해당 객체를 return 한다.

 

이 HandlerMapping 클래스 내부의 HashMap은 setter로 의존 주입을 했었다.

 

 

 

위의 이미지와 같이, 

@RequestMapping 어노테이션은,  다양한 속성을 가진다.

method = RequestMethod.GET 랑, method = RequestMethod.POST 로,

같은 value 값의 사용자 요청에 대해, 분기 처리를 할 수 있다.

 

또한,

 

반환할 데이터가 있으면, 리턴 타입으로, ModelAndView 를 사용 한다.

반환할 데이터가 없으면, 리턴 타입으로 단순, String 타입을 사용 한다.

 

이렇게 하는 이유는, 반환할 데이터가 없으면, 객체를 return 하는것 보다,

String 타입을 return 하는게 상대적으로 가볍기 때문이다.

 

반환할 데이터가 있는 경우, 참조변수명을 mav 라고 가정 하고,

mav.addObject("파라미터명", 데이터); 를 사용해, 데이터를 View로 보내준다.

mav.setViewName("main.jsp"); 과 같이, 경로도 같이 set 한다.

 

mav.addObject("파라미터명", 데이터); 는,

기존의,

request.setAttribute("bdatas", bDAO.selectAll(null)); 코드와 동일한 기능을 가진다.

 

 

 

6. Command 객체 

 

위에서,

@Controller 어노테이션을 사용해서,

메서드 시그니쳐 강제성에서 벗어나고,

그에 따른 장점과 단점에 대해 정리 했고,

 

@RequestMapping 어노테이션을 사용해서,

HandlerMapping 클래스의 기능을 대신한다고 했다.

 

 

 

스프링 프레임워크란 ?

IoC와 AOP를 지원하는 경량의 프레임워크 !

 

IoC : 제어의 역행 (내가 객체를 인스턴스화 하지 않고, 스프링 컨테이너가 대신 해준다)

 

이 개념을 반영하는 개념이 Command 객체 이다.

 

1) DS 가 초기화 될때, init() 메서드를 호출 한다.

2) DS가 사용자로부터 .do 요청을 받았을 때, doGet() 또는 doPost() 메서드를 호출 한다.

3) 요청을 받으면, @RequestMapping 어노테이션이 기능을 수행하는데,

이때, 특정한 사용자의 요청에 대한 기능을 수행 하기 위해서,

메서드를 실행 하게 된다.

 

4) 이때, 메서드 내부에서 XxxVO 자료형과 XxxDAO 자료형을 사용 한다면,

해당 자료형을 모두 참조변수를 선언하고 new 를 해줘야 하는데,

 

Command 객체 기능을 사용 하면, 개발자가 직접 new 를 작성 하지 않아도 되게 된다.

 

5) 즉, 이것이 의미하는바는, 아래와 같다.

 

>>

메서드의 인자로 작성된 필요한 특정 자료형 참조변수명 에 대해, 객체화.

 

>>

해당 객체의 setter() 처리 까지 자동으로 전부 완료.

 

6) 예시

 

 

bDAO와 mav 객체를 사용 하기 때문에,

메서드의 인자로, 필요한 해당 자료형과 참조변수명을 작성 하기.

그러면, 해당 자료형을 작성된 참조변수명으로 객체화 해주고,

자동으로 setter() 까지 호출한다.

 

View에서 해당 자료형의 프로퍼티 == 속성 == 멤버변수 == 칼럼명

과 동일한 파라미터로 데이터를 보내주면,

자동으로 해당 파라미터명에 해당하는 setter() 을 호출 하고,

데이터를 프로퍼티 == 속성 == 멤버변수 에 set 해준다.

 

여기서는, 필요한 자료형의 객체가 없기 때문에, 인자로 아무것도 넣지 않은 모습 이다.

 

 

마찬가지로, BoardVO 자료형과 BoardDAO 자료형의 객체를 사용 하기 위해서,

인자로 자료형과 참조변수명을 작성 했다.

 

 

사용자가 로그인을 하기 위해 요청을 보내면 (login.do)

@RequestMapping 어노테이션이 요청값을 읽고,

메서드를 수행 한다.

이때, 필요한 자료형이 MemberVO, MemberDAO, HttpSession 이기 때문에,

메서드의 인자로 들어가 있는 모습 이다.

 

session 주체가 회원의 mid 칼럼의 데이터를 세션으로 보내기 위해서 사용 된다.

 

 

logout은 session 주체가 현재 로그인한 회원의 회원 데이터를

세션에서 가져와서 remove 해야 하기 때문에, session 객체가 필요한 상황 이다.

 

++

 

 

위와 같이 session을 주체로 사용 하기 위해서, login 이라는 이름을 가진,

메서드의 인자로 넣어, Command 객체의 개념을 사용 하고 있다.

 

이때,  아래와 같이 javax.servlet.http.HttpSession; 으로

import 가 되는 모습을 확인 할 수 있다.

 

 

import가 될 때, javax 로 시작 하면,

 

상대적으로 무거운 import 를 하게 되는 의미인데,

 

스프링 프레임워크는 경량의 프레임워크 라는 특징을 가지기 때문에,

POJO를 의미 하지만,

 

위와 같이, 상대적으로 무거운것을 import 하는 경우에는,

 

POJO 와 Not POJO의 사이 정도로 생각 하면 될듯 하다.

 

+++

 

javax.servlet.http.HttpSession 

 

Java EE (Java Platform, Enterprise Edition)의 일부로 제공되는 패키지

 

이 패키지는 웹 애플리케이션에서 세션 관리를 위한 인터페이스와 클래스를 포함 한다.

 

세션은 클라이언트와 서버 간의 지속적인 상태 유지를 가능하게 하는 기술 이며,

 

웹 애플리케이션에서 사용자의 로그인 상태나 데이터를 유지하기 위해 사용 한다.

 

javax로 시작하는 패키지들은 Java EE의 일부이며,

서블릿(Servlet)이나 JSP(JavaServer Pages)와 같은,

웹 애플리케이션 개발에 관련된 기능들을 제공 한다.

 

이러한 패키지들은 Java EE의 스펙과 관련된 기능들로써,

웹 애플리케이션을 개발할 때 편리한 기능을 제공하지만,

Java SE (Java Platform, Standard Edition)에 비해 더 많은 기능과 클래스들을 포함 한다.

 

스프링 프레임워크는 경량의 프레임워크로서,

POJO (Plain Old Java Object)를 기반으로 애플리케이션을 개발하는 것을 지향 한다.

 

POJO는 간단하고 가벼운 일반적인 자바 객체를 의미하며,

특정한 프레임워크나 환경에 종속되지 않고 독립적으로 개발할 수 있는 객체를 의미 한다.

 

위의 경우와 같이,

때로는 웹 애플리케이션에서 Java EE의 일부 기능이 필요한 경우가 있고,

이런 경우에는 Java EE의 기능들을 활용하여 개발을 진행 하게 되며,

이로 인해 애플리케이션의 일부 부분이 무거워질 수 있다.

 

즉,

더 많은 클래스와 설정이 필요하게 되므로,

애플리케이션의 일부분은 상대적으로 무거워질 수 있다.

 

그렇더라도, 여전히 스프링의 핵심 원칙과 장점을 유지 하기 때문에,

상황에 따라 적절한 기술과 접근 방식을 선택하여 사용 하는 개념 이다.