스프링 프로젝트의 src/main/java폴더 안에 있던 파일들의 구조를 이해한 대로 정리해보았다.
사진 1, 실제로 작성한 프로젝트의 구조
사진 2, MVC구조
파일의 이름이나 구조, 패키지로 묶는 방식은 사용자의 취향에 따라 다르다. 적절히 참조하고 상속시키면 된다.
"어떤 서비스에 매칭시켜줄까?"
클라이언트(view)에서 요청이 들어올 때, 해당 요청을 수행할 화면이나 비즈니스 로직(model)을 제어하는 객체이다. 디자인패턴 중 MVC구조의 C에 해당하며, 모델과 뷰를 연결해 주는 중간다리 역할이라고 생각하면 된다.
스프링 환경에서 컨트롤러를 생성하기 위해서는 자바 파일을 만들고 @Controller어노테이션을 붙인다.
컨트롤러는 요청에 따른 처리방식을 결정할 뿐, 실제로 서비스를 수행하는 것은 model영역이다.
"이 요청을 어떻게 처리할까?"
controller에서 serviceimpl객체를 생성한 뒤 호출하는 방식으로 동작한다.
서비스 레이어에서 세분화된 비즈니스 로직을 제어하는 객체. 서비스의 구조를 결정하는 interface와 이것을 상속받아 override형태로 실제 로직을 구현하는 implementation이 있다(사진 1)
(사진 2 참조) 프레젠테이션 계층과 데이터 엑세스 계층 사이를 연결하는 역할로서 두 계층이 직접적으로 통신하지 않게 한다.
@Service 어노테이션을 사용한다. interface와 implementation으로 나뉘었다면, implementation에만 붙인다.
"DB에 접근하는 요청이 있다면 여기에서 처리하자."
service에서 dao객체를 생성한 뒤 호출하는 방식으로 동작한다.
sqlsession객체를 통해 전달받은 파라미터로 DB처리를 수행한다. resource폴더의 mapper.xml을 통하거나, 직접 적는 방식으로 sql쿼리를 넣는다.
@Repository 어노테이션을 사용한다.
주고받는 데이터 객체의 구조를 결정한다.
계층 간의 데이터 교환을 위한 객체이다. 구조를 결정함으로서 알지 못하는 데이터가 들어오는 상황을 방지한다. 말 그대로 구조만을 결정해서 멤버변수와 그에 해당하는 getter,setter만이 존재한다.
만약 DB를 사용한다면, DB의 테이블 요소들을 모두 포함하고 있어야 정상적으로 동작한다.(DB에서 사용하지 않는 변수를 추가하는 것은 문제 없다.)