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

• 예제 작성에 앞서 스프링 MVC를 이용하는 프로젝트의 수성을 이해하는 일은 전체 데이터 흐름을 보기 위해 필요하다.
• 브라우저에서 전송한 데이터를 스프링 MVC의 어떤 단계를 거쳐 실행되는지 이해한다면 문제가 발생했을 때 빠른 대처와 대안을 찾을 수 있다.
• 일반적으로 웹 프로젝트는 3-tier 방식으로 구성한다.
  
• Presentation Tier(화면계층)는 화면에 보여주는 기술을 사용하는 영역이다.
• 예제에서는 Servlet/JSP나 스프링 MVC가 담당하는 영역이 된다.
• Presentation Tier는 프로젝트의 성격에 맞춰 앱으로 제작하거나, CS(Client-Server)로 구성되는 경우도 있다.
• 스프링 MVC와 JSP를 이용한 화면 구성이 이에 속한다.

• Business Tier(비즈니스 계층)는 순수한 비즈니스 로직을 담고 있는 영역이다.
• 이 영역이 중요한 이유는 고객이 원하는 요구 사항을 반영하는 계층이기 때문이다.
• 이 영역의 설계는 고객의 요구 사항과 정확이 일치해야 한다.
• 이 영역은 주로 'xxxService'와 같은 이름으로 구성하고, 메서드의 이름 역시 고객들이 사용하는 용어를 그대로 사용하는 것이 좋다.

• Persistence Tier(영속 계층 혹은 데이터 계층)는 데이터를 어떤 방식으로 보관하고, 사용하는가에 대한 설계가 들어가는 계층이다. 일반적인 경우에는 데이터베이스를 많이 이용핳지만, 경우에 따라 네트워크 호출이나 원격 호출 등의 기술이 접목될 수 있다.
• 이 영역은 MyBatis와 mybatis-spring을 이용해서 구성했던 파트 1을 이용한다.

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

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

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

7.1.1 패키지의 Naming Convention

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