동일한 기능을 수행하더라도, 영속성계층은 영속성계층에 맞게, 비즈니스계층은 비즈니스계층에 맞게 메소드 명을 지어야 함.
(똑같이 목록을 조회하는 메소드여도, db에서는 select, 비즈니스계층에서는 getList.
똑같이 등록을 하는 메소드여도, db에서는 insert, 비즈니스계층에서는 register.)
서비스계층이 만든 추상메소드는 앞단의 컨트롤러가 이용함.
리턴타입은 void여도 되고, boolean으로 성공 실패 여부만 반환해도 됨.
컨트롤러 뒤에 - 서비스계층 뒤에 - Mapper 클래스(영속성계층)
프론트 컨트롤러가 요청을 컨트롤러에 위임하면, request mapping대로 서비스객체(기능이 구현되어있는)를 이용해서 수행.
비즈니스로직상 특정 서비스객체가 db를 건드려야 하는 경우에만 mapper interface를 이용하는거고,
필요없으면 이용 안해도 됨.
서비스객체가 돌려준 return값이 곧 model의 후보가 됨.
리턴타입은 비즈니스관점에서 어떤 데이터를 돌려줘야하는지? 비즈니스 로직에 따라 결정.
서비스객체는 뒷단에 있는 영속성계층의 mapper proxy를 이용해서 db작업을 함.
필요시마다 영속성계층의 메소드를 호출해서 이용하려면 영속성 계층의 핵심인 mapper proxy 객체를 주입받아야 함.
spring v4.3 이후부터는, 주입받을 필드가 한개이고, 이 필드를 생성자의 매개변수로 가지는 생성자를 선언하면
의존성 주입(DI) signal을 보내지 않아도(어노테이션 없어도) 스프링이 자동으로 주입을 해 줌.
@AllArgsConstructor 어노테이션만 붙여주면 됨
의존성 주입을 요구받는 생성자라면, 스프링은
등록되어있는 bean이라면 스프링이 빈즈컨테이너에 올라와있는 빈들 중에, 보드매퍼 타입에 맞는 빈을 찾으면 생성자 호출시 주입시켜 줌.
requestmapping의 설계는, 단순히 어느 컨트롤러의 어느 메소드가 호출되느냐 뿐만 아니라
이후 어떤 화면을 출력해야 하는지까지 생각해야 함. (return : ***.jsp)
컨트롤러는 요청URI + 전송파라미터가 필요 => HTTP request가 필요 => 웹 브라우저 가 필요함!
위에서 발생한 Http request를 받아서 처리할 Servlet container, 즉 WAS가 필요함!!
위의 환경을 조성해줘야 controller테스트가 가능함.
- 방법 1. WAS구동 + 웹 브라우저 사용
(대규모 웹 서비스를 만들 때는 WAS를 한 번 내렸다 올리는 데 오랜 시간이 걸림.
즉, WAS를 구동시키는 데에만 상당한 시간이 필요하다) - 방법 2. WAS를 구동시키지 않고,
스프링을 WAS와 비슷한 환경으로 만들어 주는 방법 + 웹 브라우저마저 에뮬레이션 할 수 있는 방법을
함께 제공!!
스프링 제공 방법
스프링 코어(core)가 빈즈 컨테이너(DI+빈객체 관리) 생성해줘야 함.
스프링 MVC흐름을 강제시켜야 함.
웹브라우저 에뮬레이션 => MockMvcRequest관련 클래스 제공
