3계층 구조(3 Tier Architecure)
- Presentation Tier (화면계층) :
- 사용자가 애플리케이션과 상호작용하는 애플리케이션의 사용자 인터페이스.
- Servlet/JSP나 스프링 MVC가 담당 - Business Tier(비지니스 계층):
- 순수한 비지니스 로직을 담고 있는 영역
- 고객의 요구사항을 반영하는 계층
- 주로 'xxxService'와 같은 이름으로 구성 - Persistaence Tier(영속 계층 혹은 데이터계층)
- 데이터를 어떤방식으로 보관하고, 사용하는 가에 대한 설계가 들어가는 계층
- MYBatis와 mybatis-spring를 이용한다.
이 계층을 스프링 MVC에 맞추어 구성하면 다음과 같은 구조가 된다
스프링 MVC 영역은 Presentation Tier를 구성하게 되는데, 각 영역은 사실 별도의 설정을 가지는 단위로 볼 수 있다. root-context나 servlet-context 등의 설정 파일이 Spring MVC의 설정을 담당한다. 스프링 Core 영역은 흔히 POJO(Plain Old Java Object)의 영역이다. 스프링의 의존성 주입을 이용해 객체 간의 연관구조를 완성해서 사용한다. MyBatis 영역은 mybatis-spring을 이용해서 구성하는 영역이다. 이 영역은 SQL에 대한 처리를 담당한다.
각 영역의 Naming Convention(명명 규칙)
프로젝트를 위와 같이 구성하는 가장 일반적인 이유는 유지보수에 대한 필요성 때문이다. 각 영역이 독립적으로 설계되어 나중에 특정한 기술이 변하더라도 필요한 부분을 전자제품 부품처럼 쉽게 교환할 수 있게 하는 방식이다. 그렇기 때문에 각 영역은 설계 당시부터 영역을 구분하고, 해당 연결 부위는 인터페이스를 이용해서 설계하는 것이 가장 일반적인 구성 방식이다.
보통 프로젝트를 진행할 때 다음과 같은 네이밍 규칙을 가지고 작성한다.
xxxController : Controller 클래스를 설계할 때 사용
xxxService, xxxServiceImpl : 비즈니스 영역을 담당하는 인터페이스는 xxxService라는 방식을 사용하고, 인터페이스를 구현한 클래스는 xxxServiceImpl이라는 이름을 사용
xxxDAO, xxxRepository : DAO(Data-Access-Object)나 Repository(저장소)라는 이름으로 영역을 따로 구성하는 것이 보편적이다. MyBatis를 사용하는 경우는 Mapper 인터페이스를 활용한다.
VO, DTO : VO와 DTO는 일반적으로 유사한 의미로 사용하는 용어로, 데이터를 담고 있는 객체를 의미한다는 공통점이 있다. 다만, VO는 주로 Read Only 목적이 강하고, 데이터 자체도 불변하게 설계하는 것이 정석이다. DTO는 주로 데이터 수집의 용도가 좀 더 강하다.
패키지의 구성은 프로젝트 크기나 구성원들의 성향으로 결정한다. 예를 들어, 규모가 작은 프로젝트는 Controller 영역을 별도의 패키지로 설계하고, Service 영역 등을 하나의 패키지로 설계할 수 있다.
반면에, 프로젝트 규모가 커져서 많은 Service 클래스와 Controller들이 혼재할 수 있다면 비즈니스를 단위별로 구분하고 다시 내부에서 Controller 패키지, Service 패키지 등으로 다시 나누는 방식을 이용한다. 이런 방식은 담당자가 명확해지고, 독립적인 설정을 가지는 형태로 개발하기 때문에 큰 규모 프로젝트에 적합하다. 하지만 패키지가 많아져, 구성이 복잡하게 느껴지는 단점이 있다.
프로젝트 요구사항
프로젝트를 진행하기 전에 먼저 고객의 요구사항을 인식하고 이를 설계하는 과정이 필요하다. 이를 요구사항 분석 설계라고 하는데, 고객이 원하는 내용이 무엇이고, 어느 정도까지를 구현할 것인가에 대한 프로젝트 범위를 정하는 것을 목적으로 한다.
요구사항은 온전한 문장으로 정리하는 것이 좋다. 주어는 고객이고 목적어는 대상이 된다. 여기서 대상은 결국 데이터 베이스 설계와 시스템 설계에서 가장 중요한 용어가 된다. (다른 용어로 도메인 domin 이라는 단어를 사용하는 경우도 많다) 예를들어
고객은 새로운 게시물을 등록할 수 있어야 한다.
고객을 특정 게시물을 조회할 수 있어야 한다.
고객은 작성할 게시물을 삭제할 수 있어야 한다.
이 경우 대상은 게시물이 되므로, 게시물이라는 용어가 필요하고, 게시물의 구조를 판단해서 데이터베이스 테이블을 설계하게 된다.
예를 들어, 게시물의 경우 'tbl_board'라는 테이블을 설계하고
테이블과 관련된 VO 클래스는 'com.zerock.domain.BoardVO'같은 이름으로 설계될 수 있다.
게시물과 관련된 로직은 'com.zerock.service.BoardService'가 될 수 잇고,
컨트롤러는 'com.zerockcontroller.BoardController'가 되는 연속적인 과정을 거친다.
요구사항에 따른 화면 설계
요구사항에서 나오는 용어를 기준으로 테이블이나 클래스 이름들이 정해지듯, 요구사항은 화면에도 영향을 미치게 된다. 고객이 새로운 게시물을 등록할 수 있어야 한다면 당연히 그에 해당하는 화면을 구성해야 한다. 이 구성은 어떤 내용들을 입력하게 될 것인가에 세부적인 설계가 되고, 이를 기준으로 테이블이나 클래스의 멤버 변수들을 설계하게 된다. 실제 프로젝트에서는 아래 그림과 같이 스토리보드를 결과로 만들게 된다.
스토리보드: 화면설계는 주로 Mock-up(목업)툴을 사용: PowerPoint, Balsamiq studio, Pencil Mockup 등
화면의 흐림을 URL로 구성하게 되기때문에 GET/POST방식을 기재
