other

part 3 기본적인 웹 게시물 관리

중점내용

• 스프링 MVC를 이용하는 웹 프로젝트 전체 구조에 대한 이해
• 개발의 각 단계에 필요한 설정 및 테스트 환경
• 기본적인 등록, 수정, 삭제, 조회, 리스트 구현
• 목록(리스트) 화면의 페이징(paging)처리
• 검색 처리와 페이지 이동

스프링 MVC 프로젝트의 기본 구성

예제를 작성하기에 앞서서 스프링 MVC를 이용하는 프로젝트의 구성을 이해하는 일은 전체 데이터의 흐름을
보기 위해서임
브라우저에서 전송한 데이터를 스프링 MVC의 어떤 단계를 거쳐서 실행되는지를 이해한다면 문제가 발생했을때
빠른 대처와 대안을 찾을 수 있기 때문임

일반적으로 웹 프로젝트는 3-tier(티어)방식으로 구성함
164p 그림은 Presentation <-> Business <-> Persistence 이런 방식으로 구성한다는뜻

Presentation Tier(화면 계층): 화면에 보여주는 기술을 사용하는 영역

책에선 Servlet/JSP나 스프링 MVC가 담당하는 영역이 됨
presentation Tier는 프로젝트의 성격에 맞춰 앱으로 제작하거나, CS(Client-Server)로 구성됨
이전 파트에서 학습한 스프링 MVC와 JSP를 이용한 화면 구성이 이에 속함

Business Tier(비즈니스 계층): 순수한 비지니스 로직을 담고 있는 영역

이 영역이 중요한 이유는 고객이 원하는 요구 사항을 반영하는 계층이기 때문
이 영역의 설계는 고객의 요구사항과 정확히 일치해야함 이 영역은 주로 XXXService와 같은 이름으로 구성하고
메서드의 이름 역시 고객들이 사용하는 용어를 그대로 사용하도록 하는게 좋음

Persistence Tier(영속 계층 혹은 데이터 계층): 데이터를 어떤 방식으로 보관하고,

사용하는가에 대한 설계가 들어가는 계층
일반적인 경우에는 데이터베이스를 많이 이용하지만, 경우에 따라서 네트워크 호출이나 원격 호출등의 기술이 접목됨
이 영역은 MyBatis와 mybatis-spring을 이용해서 구성했던 파트1을 이용함

계층에 대한 설명은 스프링 MVC와 맞춰서 설명해 보면 다음과 같은 구조가 됨

Spring MVC <->Spring Core <-> MyBatis <-> DB
                  ^
                  |
                  v
             Spring-mybatis(Spring Core에 속함)

스프링 MVC 영역은 Presentation Tier를 구성하게 되는데, 각 영역은 사실 별도의 설정을 가지는 단위로 볼 수 있음
이전 예제에선 root-context.xml, servlet-context.xml등의 설정 파일이 해당 영역의 설정을 담당했음
스프링 코어 영역은 흔히 POJO(Plain-Old-Java-Object)의 영역임
스프링의 의존성 주입을 이용해서 객체 간의 연관구조를 완성해서 사용함
MyBatis 영역은 현실적으로는 mybatis-spring을 이용해서 구성 SQL에 대한 처리를 담당하는 구조임

각 영역의 Naming Convention(명명규칙)

프로젝트를 위와 같이 3-tier로 구성하는 가장 일반적인 설명은 '유지 보수'에 대한 필요성 때문임
각 영역은 독립적으로 설계되어 나중에 특정한 기술이 변하더라도 필요한 부분을
전자제품의 부품처럼 쉽게 교환할 수 있게 하자는 방식임
따라서 각 영역은 설계 당시부터 영역을 구분하고, 해당 연결 부위는
인터페이스를 이용해서 설계하는게 일반적인 구성방식임

프로젝트 진행 네이밍 규칙

• xxxController: 스프링 MVC에서 동작하는 Controller 클래스를 설계할 때 사용함
• xxxService, xxxServiceImpl: 비즈니스 영역을 담당하는
  인터페이스는 'xxxService'라는 방식을 사용하고,
  인터페이스를 구현한 클래스는 xxxServiceImpl이라는 이름을 사용함
• xxxDAO, XXXRepository: DAO(Data-Access-Object)나 Repository(저장소)라는 이름으로
  영역을 따로 구성하는 것이 보편적임
  다만 책의 예제는 별도의 DAO를 구성하는 대신에 MyBatis의 Mapper 인터페이스를 활용함
• VO, DTO: VO와 DTO는 일반적으로 유사한 의미로 사용하는 용어로, 데이터를 담고 있는 객체를
  의미한다는 공통점이 있음, 다만 VO의 경우는 주로 Read Only의 목적이 강하고,
  데이터 자체도 Immutable(불변)하게 설계하는 것이 정석임
  DTO는 주로 데이터 수집의 용도가 좀 더 강함 예를 들어, 웹 화면에서 로그인 하는 정보를
  DTO로 처리하는 방식을 사용함 이 책에선 테이블과 관련된 데이터는 VO라는 이름을 사용하겠음

패키지의 Naming Convention

패키지의 구성은 프로젝트의 크기나 구성원들의 성향으로 결정함
예를 들어, 규모가 작은 프로젝트는 Controller 영역을 별도의 패키지로 설계하고,
Service 영역 등을 하나의 패키지로 설계할 수 있음

반면에, 프로젝트 규모가 커져서 많은 Service 클래스와 Controller들이 혼재할 수 있다면
비즈니스를 단위별로 구분하고(비즈니스 단위 별로 패키지를 작성) 다시 내부에서 Controller 패키지, Service 패키지 등으로 다시 나누는 방식을 이용함
이런 방식은 담당자가 명확해지고, 독립적인 설정을 가지는 형태로 개발하기 때문에
큰 규모의 프로젝트에 적합함 다만
패키지가 많아지고, 구성이 복잡하게 느껴지는 단점이 있음

이 책의 예제 구성은 PART 3 이후로는 다음과 같은 패키지를 구성할것임

              com.crow.config: 프로젝트와 관련된 설정 클래스들의 보관 패키지   
              com.crow.controller: 스프링 MVC의 Controller들의 보관 패키지
              com.crow.service: 스프링의 Service 인터페이스와 구현 클래스 패키지
              com.crow.domain:VO, DTO 클래스들의 패키지
 com.crow     com.crow.persistence: MyBatis Mapper 인터페이스 패키지
              com.crow.exception: 웹 관련 예외처리 패키지
              com.crow.aop: 스프링의 AOP 관련 패키지
              com.crow.security: 스프링 Security 관련 패키지
              com.crow.util: 각종 유틸리티 클래스 관련 패키지

프로젝트를 위한 요구사항

프로젝트를 진행하기 전에 고객의 요구사항을 인식하고, 이를 설계하는 과정이 필요함
이를 흔히 요구사항 분석 설계라고 하는데, 고객이 원하는 내용이 무엇이고,
어느정도까지 구현할 것인가에 대한 프로젝트의 범위를 정하는 것을 목적으로 함

요구사항은 실제로 상당히 방대해 질 수 있으므로, 프로젝트에서는 단계를 정확히 구분해 주는것이 좋음
만일 팀원들이 경험이 풍부하다면 초기 버전을 상당히 많은 기능을 포함시켜 개발을 진행
할 수 있지만, 그렇지 못하다면 최대한 단순하고 눈에 보이는 결과를 만들어 내는 형태로 개발할것

요구사항은 온전한 문장으로 정리하는 것이 좋음
주어는 '고객'이고 목적어는 '대상'이 됨
여기서 '대상'은 결국 데이터의 베이스 설계와 시스템 설계에서 가장 중요한 용어가됨
(다른 용어로는 도메인(domain)이라는 단어를 사용하는 경우도 많음)

EX: 게시판의 요구사항

• 고객은 새로운 게시물을 등록할 수 있어야 한다.
• 고객은 특정한 게시물을 조회할 수 있어야 한다.
• 고객은 작성한 게시물을 삭제할 수 있어야 한다.
• 기타 등등

이 경우 '대상'은 '게시물'이 되므로, 게시물이라는 용어가 필요하게 되고,
게시물의 구조를 판단해서 데이터베이스 테이블을 설계함 예를 들어 게시물의 경우 'tbl_board'라는 테이블을 설계하게 되고,
테이블과 관련된 VO 클래스 역시 com.crow.domain.BoardVO와 같은 이름으로 설계될수 있음
게시물과 관련된 로직은 com.crow.service.BoardService가 될 수 있고,
com.crow.controller.BoardController라는 이름의 클래스를 생성하는 연속적인 과정을 거치게 됨

요구사항에 따른 화면 설계