[Spring] MVC model 2 구조

[Spring] MVC model 2

MVC model2를 사용하는 이유

1. 분업 2. 유지보수 3. 페이지가 많기 때문에

스프링 MVC model 2 Front-Controller패턴의 형태

위 이미지의 숫자와 관련 없음

1. 사용자의 모든 Request는 Front-Controller인 DispatcherServlet을 통해 처리한다.(web.xml 참고)
2. HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾기 위해 존재한다.
   HandlerMapping 인터페이스를 구현한 여러 객체 중 @RequestMapping, @Controller 어노테이션이 적용된 것을 기준으로 판단하며, 적절한 컨트롤러가 찾아졌다면 HandlerAdapter을 이용해서 해당 컨트롤러를 동작시킨다.
3. Controller는 Request를 처리하는 비지니스로직을 작성하며, View에 전달해야 하는 데이터는 주로 Model객체에 담아서 전달한다.
   이에 대한 처리는 ViewResolver를 이용하게 된다.
4. ViewResolver는 Controller가 리턴한 결과를 어떤 View에서 처리하는 것이 좋을 지 해석하는 역할이다. (Servlet-context.xml 참고)
5. 만들어진 응답은 DisparcherServlet을 통해서 전송된다.

Spring MVC Controller 특징

• HttpServletRequest, HttpServletResponse를 거의 사용할 필요 없이 기능을 구현할 수 있다.
• 다양한 타입의 파라미터 처리, 다양한 타입의 리턴 타입 사용 가능
• GET방식, POST방식 등 전송 방식에 대한 처리를 어노테이션으로 처리 가능
• 상속/인터페이스 방식 대신 어노테이션만으로도 설정 가능

---

Spring MVC 프로젝트의 기본 구성

스프링 MVC에서 어떤 단계를 거쳐서 실행되는 지를 이해해야 문제 발생 시 빠른 대처와 대안을 찾을 수 있다.

웹 프로젝트는 3-tier(티어)방식으로 구성한다.

Presentation <-> Business <-> Persistence

Presentation Tier(화면 계층)

화면에 보여주는 기술을 사용하는 영역이다. (View)

Servlet/JSP 혹은 스프링 MVC가 담당하는 영역이며 화면 구성이 이에 속한다.

Business Tier(비지니스 계층)

순수한 비지니스 로직을 담고 있는 영역이다.

고객이 원하는 요구사항을 반역하는 계층이기 때문에 중요한 영역이다.

이 영역의 설계는 고객의 요구사항과 정확히 일치해야 하며, '000Service'와 같은 이름으로 구성한다.

Persistenct Tier(영속 계층 혹은 데이터 계층)

데이터를 어떤 방식으로 보관하고, 사용하는 가에 대한 설계가 들어가는 계층이다.

일반적으로 DB를 많이 이용하지만, 상황에 따라서 네트워크 호출 혹은 원격 호출 등의 기술이 접목된다.

계층 관계도
[Spring MVC] <-> [Spring Core] <-> [Spring-mybatis] <-> [MyBatis] <-> DB

각 영역은 독립적으로 설계되어 나중에 특정한 기술이 변하더라도 필요한 부분을 전자제품의 부품처럼 쉽게 교환할 수 있게 하는 방식이다.

각 연결 부위는 인터페이스를 이용해서 설계하는 것이 일반적인 구성 방식이다.

---

Naming Convertion(명명 규칙)

com.XXXX.[패키지명]

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

---

비지니스 계층

프레젠테이션 계층과 영속 계층의 중간다리 역할을 한다.

영속 계층은 DB를 기준으로, 비지니스 계층은 로직을 기준으로 처리한다.

예를 들어 쇼핑몰에서 상품 구매 시 포인트 적립을 한다고 가정한다면, 영속 계층의 설계는 '상품', '회원'으로 나누어 설계하지만, 비지니스 계층은 상품 영역과 회원 영역을 동시에 사용해서 하나의 로직을 처리하게 된다.

Business Tier <- Service <- Persistence

Persistence에서 두개의 메소드로 하나의 트랜잭션을 이룰 때, Service에서 하나의 메소드로 모으고, Business Tier에서는 Service의 메소드 하나만 이용한다.

*일반적으로 비지니스 영역에 있는 객체들은 서비스(Service)라는 용어를 많이 사용한다.

 

service 인터페이스를 구성하고, service인터페이스를 implement하여 생성한 클래스에서 메소드의 내용을 구성하는 이유는 실 제 사용할 때에 service 인터페이스 객체에 implement한 클래스를 주입하여 이용함으로써 재사용, 느슨한 결합성을 만족시킨다.

---

의존성 주입

순서

1. 준비 @Component, @Service, @Controller, @Repository, <bean> 등을 통해 사용한다. root-context.xml에 작성된 등록된 Bean이 Context에 할당된다.
2. 주입 @AutoWired -> root-context.xml -> 주입
   @Qualifier("A")를 사용하면 동일한 타입 중 골라서 주입할 수 있다.
   *A: id를 설정했다면 id값 작성, 어노테이션으로 설정했다면 해당 클래스의 앞글자만 소문자로 변경된 id값 작성
   예) <bean id="a" ...> @Qualifier("a")
   @Repository
   Class A_Repository -> @Qualifier("a_Repository")

목적

해당 필드를 사용하는 로직에서 다양한 선택을 할 수 있도록 설계하기 위함.

선언부와 사용부의 주소를 같이 공유해야 하며, 개발의 유연성을 유지하기 위함이다.