[꼼꼼한 개발자] 꼼코더
26. 코드로 배우는 스프링 웹 프로젝트 - [스프링 MVC 프로젝트의 기본 구성] - 3-tier(티어) 방식, Naming Convention(명명 규칙), 패키지의 Naming Convention(명명 규칙) 본문
26. 코드로 배우는 스프링 웹 프로젝트 - [스프링 MVC 프로젝트의 기본 구성] - 3-tier(티어) 방식, Naming Convention(명명 규칙), 패키지의 Naming Convention(명명 규칙)
꼼코더 2023. 1. 6. 01:03👀 스프링 MVC 프로젝트의 기본 구성
스프링 MVC를 이용하는 프로젝트의 구성을 이해하는 것은 전체 데이터 흐름을 보는 것이다.
브라우저에서 전송한 데이터를 스프링 MVC의 어떤 단계를 거쳐 실행되는지 이해해야
문제 발생 시 빠른 대처와 대안을 찾을 수 있기 때문이다.
일반적인 웹 프로젝트는 3-tier(티어) 방식으로 구성된다.
🖥 Presemtatiom Tier(화면계층)
- 화면에 보여주는 기술을 사용하는 영역
- 예제에서는 Servlet/JSP나 스프링 MVC가 담당하는 영역
- 프로젝트의 성격에 맞춰 앱으로 제작하거나 CS(Client-Server)로 구성되는 경우도 있다.
- 이전 글들에서 스프링 MVC와 JSP를 이용한 화면 구성이 이에 속한다
👷🏻♂️ Business Tier(비즈니스 계층)
- 순수한 비즈니스 로직을 담고 있는 영역
- 이 영역이 중요한 이유는 고객이 원하는 요구사항을 반영하는 계층이기 때문
- 설계시 고객의 요구 사항과 정확히 일치하게 설계해야 한다.
- 주로 ‘xxxService’와 같은 이름으로 구성한다
- 메서드의 이름역시 고객들이 사용하는 용어 그대로 사용하는 것이 좋다.
🗳 Persistencs Tier(영속 계층 혹은 데이터 계층)
- ‘데이터를 어떤 방식으로 보관하고, 사용하는가’에 대한 설계가 들어가는 계층
- 일반적으로 데이터베이스를 많이 이용한다, 하지만 네트워크 호출, 원격 호출들의 기술도 접목될 수 있다.
- 이전에 MyBatis와 mybatis-spring을 이용해서 구성했던 예제에서 다뤄봤다.
위 계층에 대한 설명을 스프링 MVC와 맞춰서 설명해 보면 다음과 같은 구조가 된다.
스프링 MVC 영역은 Presemtatiom Tier로 구성한다.
이전 예제에서는 root-context.xml, servlet-context.xml 등의 설정 파일이 해당 영역의 설정을 담당하였다.
스프링 Core 영역은 흔히 POJO(Plain-Old-Java-Object) 영역이다.
스프링의 의존성 주입을 이용해서 객체 간의 연관 구조를 완성해서 사용한다.
Mybatis 영역은 현실적으로는 mybatis-spring을 이용해서 구성하는 영역이다.
SQL에 대한 처리를 담당하는 구조이다.
🎫 각 영역의 Naming Convention(명명 규칙)
프로젝트를 3-tier로 구성하는 이유는 ‘유지 보수’에 대한 필요성 때문이다.
이처럼 독립적으로 설계 시 추후 기술이 변하더라도 변경된 부분을 부품처럼 쉽게 교환할 수 있다.
따라서 각 영역은 설계 당시부터 영역을 구분하고
해당 연결 부위는 인터페이스를 이용해서 설계하는 것이 일반적인 구성방식이다.
프로젝트를 진행할 때에는 다음과 같은 네이밍 규칙을 가지고 작성한다
xxxController
- 스프링 MVC에서 동작하는 Controller 클래스를 설계할 때 사용
xxxService, xxxServiceImpl
- 비즈니스 영역을 담당하는 인터페이스는 ‘xxxService’이름을 사용
- 인터페이스를 구현한 클래스는 ‘xxxServiceImpl’이름을 사용
xxxDAO, xxxRepository
- DAO나 Repository 라는 이름으로 영역을 따로 구성하는 것이 보편적
- 하지만 이 책에 예제는 별도의 DAO 구성 대신 MyBaris의 Mapper 인터페이스를 활용
VO, DTO
- VO와 DTO는 ‘데이터를 담고 있는 객체’를 의미한다는 공통점이 있다.
- 다만, VO의 경우 주로 Read Only의 목적이 강하고, 데이터 자체도 ‘Immutable(불변)’하게 설계한다.
- DTO는 주로 데이터 수집의 용도가 좀 더 강하다
- 예) 웹 화면에 로그인하는 정보는 DTO로 처리, 이 교재에서는 테이블 관련 데이터는 VO이름을 사용
🤝 패키지의 Naming Convention(명명 규칙)
패키지의 구성은 프로젝트의 크기, 구성원들의 성향으로 결정된다.
예시로 규모가 작은 프로젝트는 Controller 영역을 별도의 패키지로 설계하고, Service 영역 등을 하나의 패키지로 설계할 수 있다.
반면, 프로젝트의 규모가 커져 많은 Service 클래스와 Controller들이 혼재할 수 있다면
비즈니스를 단위별로 구분하고(비즈니스 단위 별로 패키지를 작성하고)
다시 내부에서 Controller 패키지, Service 패키지 등으로 다시 나누는 방식을 이용한다.
이런 방식은 담당자가 명확해지고, 독립적인 형태로 개발하기 때문에 큰 규모의 프로젝트의 적합하다.
지금부터 아래 그림과 같은 패키지 구성으로 실습할 예정이다.
🧹 최종 정리
- 브라우저에서 전송한 데이터를 스프링 MVC의 어떤 단계로 처리되는지 이해해야 문제 발생 시 빠른 대처와 대안을 찾을 수 있다
- 일반적인 웹 프로젝트는 3-tier(티어) 방식으로 구성된다.
- Presemtatiom Tier(화면계층)
- 화면에 보여주는 기술을 사용하는 영역
- 이전 글들에서 스프링 MVC와 JSP를 이용한 화면 구성이 이에 속한다
- Business Tier(비즈니스 계층)
- 순수한 비즈니스 로직을 담고 있는 영역
- 이 영역이 중요한 이유는 고객이 원하는 요구사항을 반영하는 계층이기 때문
- 주로 ‘xxxService’와 같은 이름으로 구성한다
- Persistencs Tier(영속 계층 혹은 데이터 계층)
- ‘데이터를 어떤 방식으로 보관하고, 사용하는가’에 대한 설계가 들어가는 계층
- 일반적으로 데이터베이스를 많이 이용한다, 하지만 네트워크 호출, 원격 호출들의 기술도 접목될 수 있다.
- 이전에 MyBatis와 mybatis-spring을 이용해서 구성했던 예제에서 다뤄봤다.
- 스프링 MVC 영역은 Presemtatiom Tier로 구성한다.
- 예제에서는 설정 파일이 해당 영역의 설정을 담당(root-context.xml, servlet-context.xml 등)
- 스프링 Core 영역은 흔히 POJO 영역이다.
- 스프링의 의존성 주입을 이용해서 객체 간의 연관 구조를 완성해서 사용한다.
- Mybatis 영역은 현실적으로는 mybatis-spring을 이용해서 구성하는 영역이다.
- SQL에 대한 처리를 담당하는 구조이다.
위 내용은 코드로 배우는 스프링 웹 프로젝트 교재를 참고하여 작성되었습니다.