Spring(17) - 웹 어플리케이션 구조

웹 어플리케이션을 만들 때 가장 쉽고 많이 사용되는 구조가 바로 서비스-DAO구조입니다.
초보개발자들이 가장 이해하기가 쉽고 설계하기가 쉽기때문에 처음에는 이구조로 접근하는것이 좋습니다.

서비스-DAO구조의 각 구성 요소별 역할은 다음과 같습니다.

구성 요소	역할
모델	DB테이블과 관련된 클래스가 위치한다. 서비스 - DAO간 데이터를 주고받기 위한 객체로도 사용된다.
DAO	DB테이블에 대한 CRUD기능을 정의한 클래스이다. 데이터 입력, 수정, 조회 시 데이터타입을 모델로 사용한다.
서비스	컨트롤러를 통해서 전달받은 사용자의 요청을 정의한다. DB연산이 필요할 경우 DAO를 이용한다.
컨트롤러	사용자의 웹요청을 받아 서비스나 DAO로 전달하고, 결과를 뷰로 전달한다.

스프링 기반 어플리케이션에서는 컨트롤러, 서비스, DAO가 각각 스프링 빈으로 등록되며 서로 DI를 이용해 의존관계를 유지합니다.(@Controller, @Service, @Repository를 이용)

DAO구현

DAO클래스를 작성할 때는 조회기준이 되는 테이블마다 하나의 DAO를 작성하는게 원칙입니다.
ex) 회원테이블, 회원상세정보테이블이 있을 경우 각각 DAO를 만듬(memberDAO, memberDetailDAO)

Service구현

서비스는 사용자 기능을 정의하는 클래스(인터페이스)입니다. 보통 사용자 기능을 정의만 해놓은 인터페이스를 작성하고, 그것을 구현한 서비스Impl클래스를 만들어 그안에서 몸체를 정의해 사용하는 것이 일반적입니다.

package service;
 
public interface memberService {
    public void insertMemberInfo() throws Exception;
    public void updateMemberInfo(String memberId) throws Exception;
    public void deleteMemberInfo(String memberId) throws Exception;
    public Member selectMemberInfo(String memberId) throws Exception;
}
 

위 인터페이스처럼 기본적인 회원정보의 CRUD작업을 정의한 인터페이스를 만들고

package service;
 
import javax.annotation.Resource;
 
public class memberServiceImpl implements memberService{
    @Resource(name="memberDAO")
    MemberDAO memberDAO;
    
    @Override
    public void insertMemberInfo() throws Exception {
        // TODO Auto-generated method stub
        memberDAO.insertMemberInfo();
    }
 
    @Override
    public void updateMemberInfo(String memberId) throws Exception {
        // TODO Auto-generated method stub
        memberDAO.updateMemberInfo(memberId);
    }
 
    @Override
    public void deleteMemberInfo(String memberId) throws Exception {
        // TODO Auto-generated method stub
        memberDAO.deleteMemberInfo(memberId);
    }
 
    @Override
    public Member selectMemberInfo(String memberId) throws Exception {
        // TODO Auto-generated method stub
        return memberDAO.selectMemberInfo(memberId);
    }
 
}
 

이렇게 인터페이스를 구현해서 DAO와 연동하는 ServiceImpl을 만들 수 있습니다. 만약 인터페이스에 메서드가 많이 정의된다면 인터페이스의 특성상 그것을 구현한 클래스에서 인터페이스의 모든 메서드를 재정의해야하는데, 필요없는 메서드가 있을 수도 있습니다. 그렇기때문에 인터페이스내에서 또 인터페이스를 빼내어서 필요한메서드별로 나누어서 인터페이스를 작성하는 것도 종은 방법입니다.

위와같이 Service클래스에서 단순히 DAO에게 조회, 삭제, 수정, 삽입 기능을 위임만하고 끝낸다면 사실 ServiceImpl이 있을 필요가 없습니다. 그냥 Controller에서 바로 DAO로 접근해 원하는 기능을 넣는 것도 한가지 방법입니다. 다만 서비스-DAO구조의 일관성을 가져가기 위해서 이렇게 사용하는 것입니다.

설계에는 정답이 없으니 각자에게 맞는 방식을 찾아서 개발하면 될 것 같습니다.