2019/01/07

2019/01/07 

​

[지난시간 정리01]

​Dispatcher servlet은 서블릿의 역할과 스프링컨테이너 역할을 같이 하기 떄문에, 스프링 설정파일이 필요하며, 해당 파일의 경로를 <init-param>에 적어주게 된다.

handlermapping, controller,viewResolver 등 스프링 컨테이너에 스프링 구성요소를 bean으로 만들고 등록해서 사용. 

이때 handlermapping와 viewResolver은 스프링에서 지원해주는 기본 객체가 존재하기에 별도로 생성 할 필요가 없다. 단, controller (실제 로직수행)은 사용자가 따로 만들어서 bean으로 등록하고 사용하여야 한다.

​

[지난시간 정리02]​

실제 로직 처리를 위해서 service 객체가 필요하고 bean으로 등록되어 있는 service 객체를 의존성 주입받아서 사용하게 된다.

​

[지난시간 정리03]​

ModelAndView 객체는 왜 bean으로 등록하지 않나?

ModelAndView은 요청마다 다른 결과를 만들어 내야한다. 즉, 객체가 같은 값을 가지면서 계속 유지되는게 아니기 때문이다.

DAO를 작성 할 때, 모델 객체를 멤버변수로 등록하고 사용하는 것이 아닌 각 메서드 마다 따로따로 필요할 때 마다 모델 객체를 선언 및 생성 했던 것과 같은 이치임.

​

​

[Spreing MVC 구조 이해하기]

[준비하기]

1.Maven프로젝트로 변경해서 dependency 설정

Spring : core,context,jdbc,aop,web,webmvc,test

MyBatis : mybatis,Mybatis-spring

oracle : ojdbc

Aspectj : aspectjrt,aspectjweaver

test : junit

기타 : log4j, jstl

2. web.xml에 dispatcher-servlet 등록

이미지) web.xml에 등록

이미지)스프링컨테이너 생성 및 컨트롤​러 등록 

이미지)컨트롤러 클래스 생성 및 테스트 
​

​
3. web.xml에 공용컨테이너 등록하기

spring에서 공용컨테이너를 위한 클래스를 제공 : ContextLoaderListener

디스패쳐서블릿의 경우 서블과 스프링컨테이너 역할을 하기 위해서 만들어졌고, 공용 컨테이너의 경우 Listerner에 스프링 컨테이너 기능을 달아준 형태이다. 

​

리스너 ? 특정한 이벤트가 발생했을 때, 해당 이벤트를 인지하고 동작하는 객체

​

공용컨테이너가 사용하는 리스너는 context가 로딩되면 로딩 이벤트가 동작하는 객체이다. 그래서 이름이 'ContextLoaderListener'

​

context가 로딩된다 ? 우리가 작성한 프로그램이 웹컨테이너(톰캣)에 올라가서 객체가 만들어 질 때를 뜻 한다.

​

간단정리 : 

우리가 만든 프로젝트가 웹서버에 로딩이 되면 동작하는 객체가 공용컨테이너 클래스 (ContextLoaderListener) 이다.

스프링에서 ㅐ당 리스너를 만들어서 제공하고, 내부적으로 스프링 컨테이너를 하나 만들어주는 동작을 한다. >> root-container

​

Webcontent/WEB-INF/applicationContext.xml 해당 경로를 찾아가서 스프링 컨테이너 설정파일로 사용하도록 기본 설정 되어있다. 

[root-container (공용 컨테이너) 등록하고 사용하기]

두 개의 각기 다른 서블릿이 존재한다고 했을 떄, 핸들러매핑과 컨트롤러는 특정 요청에 따른 어떤 로직을 수행 할 지 각각 결정과 로직수행을 하기 때문에 범용으로 사용되지 않아, 각각 스프링컨테이너에 bean으로 들고 있어도 상관이 없지만. 

DAO와 Service와 같은 공통으로 사용 될 수 있는 객체들은 공용컨테이너에 등록해서 같이 사용하도록 설정 할 수 있다. 

​

​

[실습]

addStudent.jsp : 학생 정보를 입력할 수 있는 화면

addStudentForm : 입력 화면 요청

​

​

[viewName 간략화 하기 : vierResolver]

앞 쪽에는 jsp/ 뒤 쪽에는 .jsp가 중복되는 것을 확인 할 수 있다.

prefix : 항상 앞 쪽에 오게되는 것

suffix : 항상 뒤 쪽에 오게 되는 것 

이미지 처럼 앞 뒤 중복되던 키워드를 생략한체 작성을 해도 이전과 동일하게 작동된다.

​

[Controller 메서드 (handler) 반환형 알아보기]

현재 컨트롤러에서 반환형으로 사용하고 있는 것은 ModelAndView 객체이다. ModelAndView 객체는 화면 정보와 데이터를 둘 다 포함하고 있는 객체이다.

이 밖에 반환형으로 사용 될 수 있으며, 제일 많이 사용되는 반환형 타입은 String 이다. String은 화면 이름을 반환하는데, handler가 문자열을 반환하면 해당 문자열을 'viewName'으로 간주한다.

이미지에 보이는 것 처럼 return 값에 들어가는 반환값을 jsp 이름이 아닌 임의로 작성하여 오류를 발생 시키는 것으로 반환형이 String이면 해당 메서드는 viewName으로 간주된다는 것을 확인 할 수 있다.

즉, 단순하게 화면을 전환하는 메서드라면 굳이 ModelAndView 객체를 만들 필요없이 반환형 타입을 String으로 하고, 전환할 jsp를 return에 적어주면 된다는 것을 알 수 있다.

반환형 타입을 String으로 하면서, 특정 데이터를 보내는 방법도 존재한다. 바로 Controller 메서드에 파라미터로 Model을 추가하면, 화면으로 데이터를 전달 할 수 있다.​

이미지 처럼 메서드의 파라미터로 Model 객체 (org.springframework.ui.Model) 받아와서 이미지 처럼 model 객체의 addAttribute를 이용하게 되면 기본객체를 이용해서 데이터를 담아 보내는 것과 같은 역할을 한다.

반환형 타입을 void로 작성하게 되면, 요청명을 view Name으로 간주하게 된다.

예를 들어서 /studentList 라는 요청을 받았을 떄 해당 메서드가 void인 경우, viewName으로 'studentList'를 간주한다.
추가적으로 /studentList.do 일때도 "studentList"를 view Name으로 간주한다.

​

 

[컨트롤러 모듈화 하기?]

​

요청을 studentList로 한 모습

​요청을 student/studentList로 한 모습 ​요청을 student/studentList로 한 모습 

요청은 제대로 들어오게 되지만, 경로와 관련되어 오류가 발생하게 된다. 이러한 문제는 앞쪽에 /student 경로가 추가되서 발생한 문제이다.

view를 찾아 갈 때 기본 경로를 기준으로 해서 찾아가도록 설정하면 해당 문제를 해결 할 수 있다. : viewResolver에서 설정

설정 변경 전

설정 변경 후

문제해결을 위해서 변경한 점은 단순하게 prefix의 설정값이 jsp/ 이었던 것을 /jsp/로 바꾼 것 여기서 ' / ' 는 기본 경로를 설정해주는 역할을 하게 된다.

: 현재 요청에서 자신의 경로를 찾아가라는 의미

설정 변경 후 올바르게 작동하는 모습 

​

[학생정보 입력 받아서 요청 처리하기]

+ Controller 메서드에서 파라미터 받아오기

학생정보 입력 요청 : /addStudent

​

파라미터 받아오기 

: 요청 파라미터와 동일한 이름의 파라미터 선언하기 

ex ) 'name'이라는 요청 파라미터를 받아오기 위해서

　　public String test(String name){

　　​---중략---

　　​}

* 요청파라미터  : form에서 넘어오는 데이터 

테스트 결과

요청 파라미터는 모두 문자열이지만,  handler 파라미터에 숫자로 정의하면 자동으로 변환해서 값을 받아오게 된다.

화면을 전활 할 떄 redirect(새창 띄우기)를 하고 싶은 경우 에는 단순하게 앞에 redirect: 을 적어주면 된다.
​

​
[form의 action 값, 요청 값]

학생 정보를 입력받는 jsp 화면에서 submit의 액션 값으로 /student/addStudent으로 적는 것이 아닌 위 이미지 처럼 addStudent로 적는 이유

'입력' 이라는 버튼을 눌러서 form 요소의 submit 이벤트가 발생하게 되면 이미지상 빨간색으로 체크된 부분에 해당하는 값만 action 태그에 입력한 값으로 변경되기 때문에 form 요소에 앞 쪽에 있는 값 (/student)를 적지 않고 실질적인 요청 값만 적어주어도 된다.

이유 : 

입력을 받는 화면에서 submit 버튼 클릭으로 form action이 발생하게 되면, 현재 요청에서 단순하게 맨 뒷부분 요청값만 변경 되게 되는 것.

[http://localhost:8081/Day190107_SpringMVC/student/addStudentForm]

>> [http://localhost:8081/Day190107_SpringMVC/student/addStudent]​

​

​

[다시 원래 내용이어서 ...]

​service에 addStudent() 만들기

Controller에 /addStudent에 따른 코드 작성하기

*sysout은 값이 제대로 들어오는지 확인용 
​

​
[mapping 예외]

@handler에 선언된 파라미터의 이름으로 여청 파라미터가 들어오지 않으면, Mappiong 예외가 발생한다. 요청파라미터와 handler 파라미터가 이름이 다를 경우 

@RequestParam을 이용해서 매핑 시켜줄 수 있다.

​

[모델 클래스를 그대로 이용해서 파라미터 값 받아오기]

요청 파라미터의 이름과 모델클래스 (VO,DTO)의 속성이름이 같으면 해당 모델 클래스로 요청 파라미터를 얻어올 수 있다.

요청파라미터 값 살펴보기

모델 클래스 (Student)  속성 이름 살펴보기

모델 클래스가 아닌 Map을 통해서도 앞선 예제처럼 값을 받아올 수 있다. 단, 이때는 Map 앞에 @RequestParam을 붙여주어야 한다.

​

​

[실습!]

User 정보를 입/출력 하는 프로젝트 작성하기 

*usertable에 CRUD

​

화면목록 

addForm.jsp : user 정보 추가 화면

└사용자에게 ID,PW,이름 입력 받아서 DB에 추가하기 위한 화면

userList.jsp : user 목록 전체 조회 화면

└시작화면임, 추가 버튼 누르면 유저 정보 입력화면으로 이동

└사용자 목록을 출력하는데,  아이디만 출력

└아이디를 선택하면 해당 유저 상세화면으로 이동 

userDetail.jsp : user 상세 조회 화면 

└선택된 유저의 아이디,이름,비번 모두 출력 

​
​요청목록

/userList : 회원 전체 목록 조회 요청 

/addUserForm : 유저 추가화면 요청 

/addUser : 유저 추가요청, 처리 후 리스트로 이동 

/userDetail : 특정유저 상세보기 화면으로 이동

​

클래스 이름

controller : UserController

service : UserService(intetface), UserServiceImp(class)

dao : UserDao(interface)

​

​

​

​

​

​

​

​

​

​