도서 정보 제공 웹 서비스 - 메세지 읽기, Spring, Mybatis 프레임워크

메시지 읽기 기능을 구현하는 과정을 설명하기 전에 먼저 웹서비스의 전반적인 구조를 변경했음을 밝힌다.

기존에는 스프링 프레임워크, 마이 바티스 프레임워크 등, 프레임워크의 도움을 받지 않고

라이브러리 추가부터 의존관계 구성, MVC 패턴으로 설계 등등 많은 것들을 직접 구현했었다.

 

 

 

 

 

하지만 스프링 프레임워크를 사용하지 않고는 DAO, Service, Controller 등의 클래스 객체들이 각각의

객체들의 정보를 담아두도록 일일이 생성자 및 setter( ) 메서드를 설정하기란 번거로운 일이었고

 

 

 

 

또한 마이바티스 프레임워크 없이 DAO클래스에서 질의를 수행할 때에는

일일이 SQL문을 작성해주어야 했기에 상당히 가독성도 떨어지고,  SQL문을 작성하는 것도 어려웠다.

 

 

 

 

특히 DBMS에서 단일 SQL문에 대해서는 ACID를 제공하지만

한 번에 여러 SQL문을 수행해야 할 때 여러 사용자가 공유하는 데이터에 대한 동기화가 문제였다.

(가령 새로운 메시지에 사용할 메세지 ID를 얻을 때 MAX(MESSAGE_ID)를 사용할 때)

 

 

 

 

만약 동시에 여러 사용자가 메시지 전송을 수행한다면 분명히 같은 MESSAGE_ID를 할당받으므로

기본키 제약조건에 위반되는 문제가 발생할 것이다.

이러한 문제점들을 스프링과 마이 바티스 프레임워크를 사용하여 쉽게 해결할 수 있음을 배웠다.

 

 

 

 

 

 

 

물론 처음부터 스프링, 마이 바티스 프레임워크를 배운 것이 아닌 상태로 해당 프로젝트를 시작했기에

당연히 소스코드의 전반적인 부분을 수정할 수밖에 없었다. 그러나 모두 수정해야 하는 것은 아니었다.

 

 

 

 

 

 

간단히 말하자면, 기존 정적인 리소스들, HTML, CSS, JS 등의 코드는 거의 변화가 없었다.

다만, 기존에 수동으로 구성했던 MVC패턴 구조, SQL 질의, 의존관계, 파라미터 형식 등등...

정적인 부분 외에 나머지 리소스, 코드들은 수정이 불가피했다.

 

 

 

 

대략적인 구조의 모습, 큰 틀에서 보면 거의 변화가 없는 듯 하다.

 

 

 

 

 

 

 

 

 

 

메시지 읽기를 구현하는 방식은 간단하다.

 

 

qweqweqwe 아이디로 로그인 했을때 메세지 송신함의 모습, 메세지 제목 클릭시 message 컨트롤러에 readMessage.do 요청을 수행한다.

메세지메시지 리스트를 얻어와 동적으로 메시지 목록을 자바스크립트로 생성하면

a 태그의 href 속성을 통해 message 컨트롤러에 readMessge.do 요청을 수행한다.

 

이때 GET방식으로 송신함인지 수신함인지를 나타내는 MESSAGE_BOX 값

해당 메시지의 ID인 MESSAGE_ID값을 같이 전송한다.

 

 

 

 

 

 

 

	@RequestMapping(value="/message/readMessage.do")
	public ModelAndView readMessageForm(@RequestParam HashMap<String,String> info, HttpServletRequest request, HttpServletResponse response) {
		HttpSession session = request.getSession(true);
		CustomerVO customerVO = (CustomerVO) session.getAttribute("CUSTOMER");
		if(customerVO == null) {
			return new ModelAndView("mainForm");
		}else {
			info.put("CUSTOMER_ID", customerVO.getCUSTOMER_ID());
			MessageVO messageVO = messageService.readMessage(info);
			if(messageVO != null) {
				ModelAndView mav = new ModelAndView("readMessageForm");
				mav.addObject("MESSAGE_BOX", info.get("MESSAGE_BOX"));
				mav.addObject("messageVO", messageVO);
				return mav;
			}else {
				return new ModelAndView("receiveMessageForm");
			}
		}
	}

메시지 컨트롤러에서는 readMessage.do에 대한 요청을 위와 같이 처리한다.

우선, 세션에서 사용자 정보를 얻어온다.

 

 

 

만약 사용자 정보가 null이라면 로그인 정보가 더 이상 유효하지 않은 것이므로 메인화면으로 이동한다.

로그인 정보가 유효하다면, 해당 메시지가 정말 자신의 것인지 검증하기 위해 사용자 ID를 info 해시 맵에 추가한다.

그리고는 서비스 객체의 readMessage( ) 메서드를 실행한다.

 

 

 

이때 info 해시 맵은 @RequestParam 어노테이션을 통해 생성된 것임에 유의해야 한다.

스프링 프레임워크의 기능 덕분에 일일이 request.getParameter( ) 메서드를 사용하는 번거로움을 줄였다.

 

 

 

 

 

 

	public MessageVO readMessage(HashMap info) {
		return messageDAO.readMessage(info);
	}

서비스 객체에서는 따로 수행할 작업 없이 바로 DAO클래스의 readMessage( ) 메서드를 실행한다.

 

 

 

 

 

 

 

	public MessageVO readMessage(HashMap<String,String> info) {
		try {
			if(info.get("MESSAGE_BOX").equals("MESSAGE_RECEIVED")) {
				info.put("OWNER_ID", "RECEIVER_ID");
				return (MessageVO)sqlSession.selectOne("message.readMessage", info);
			}else {
				info.put("OWNER_ID", "SENDER_ID");
				return (MessageVO)sqlSession.selectOne("message.readMessage", info);
			}
		}catch(Exception e) {
			e.printStackTrace();
			return null;
		}
	}

DAO클래스에서는 이전에 전달받은 info 해시 맵을 파라미터로 사용할 것이다.

이때, 송신함의 메시지를 얻어오고자 하는 것이라면 당연히 SENDER_ID가 자기 자신이어야 하고

수신함의 메시지를 얻어오고자 하는 것이라면 RECEIVER_ID가 자기 자신이어야 하므로 그에 따라 OWNER_ID를 설정한다.

 

 

 

 

 

	<select id="readMessage" parameterType="java.util.HashMap" resultType="com.spring.LibraryService.vo.MessageVO">	
		SELECT *
		FROM ${MESSAGE_BOX}
		WHERE MESSAGE_ID = ${MESSAGE_ID} AND ${OWNER_ID} = #{CUSTOMER_ID}
	</select>

마이 바티스 프레임워크의 message 맵퍼에는 위와 같이 SELECT문이 정의되어있다.

여기서 눈여겨보아야 할 것은 바로 ${ }와 #{ }의 차이인데

보통 칼럼명이나 테이블명, 숫자의 경우 SQL문을 작성할 때에는 ' '기호로 감싸지 않는다.

즉, ' '기호 없이 파라미터로 전달된 값을 그대로 사용할 때에는 ${ }를 사용한다.

만약 문자열과 같이 ' '기호로 감싸야할 때에는 #{ }를 사용한다.

 

 

그렇게 HashMap의 형태로 파라미터를 전달받고, MessageVO의 형태로 결과를 리턴한다.

그리고 컨트롤러에서는 그렇게 얻어온 MessageVO 객체와 송, 수신 함중 어떤 메시지 함인지

구분하기 위한 MESSAGE_BOX 값을 ModelAndView객체에 담고 리턴한다.

 

 

 

 

스프링 프레임워크에서 자동으로 생성한 코드

스프링 프레임워크에서 뷰 네임 리졸버 빈을 자동으로 생성하고 설정했기에

return 모델 뷰 객체를 사용하면 알아서 /WEB-INF/views/의 jsp파일을 선택한다.

 

 

 

 

 

 

메세지 내용을 제대로 읽어온 모습

 

 

메시지 삭제나 목록보기의 경우는 앞서 메시지 리스트를 얻어오는 receiveMessage.do를 구현할 때

이미 구현해둔 deleteMessage.do와 receiveMessageForm.do를 요청하기만 하면 되기에 따로 설명하지는 않겠다.

 

 

 

 

 

대략적인 시연 동영상, 목록보기, 삭제하기, 메세지 읽기가 제대로 구현되어있다.