myBatis Interface 방식 사용시
- 작성자 :
- 권*윤
- 작성일 :
- 2014-12-18 10:25:50
- 조회수 :
- 713
- 구분 :
- 개발환경
- 진행상태 :
- 완료
Q
안녕하세요, 아래 myBatis 관련 답변 잘 확인 후 조치 하였습니다.
초기 설치 및 세팅 시에 제공되는 기본 샘플 모듈인데 조금 더 신경써서
소소한 버그없이 가급적인 소스 뎁스도 나름 권장하는 방식으로 잘 정리하여 제공하면 좋지 않을까 라는 생각이 듭니다.
스페이스 한칸 탭 한칸 잘못 들어가 있는 게 간간히 눈에 띄어 샘플 소스로서의 신뢰감이 좀 떨어져 보이곤 합니다.
물론, 추가적으로 별도로 제공되는 템플릿이나 지속적으로 제공되는 콤포넌트 등 참고하여 활용하고 있어 늘 감사드립니다.
추가적인 질문입니다.
이번에 진행되는 프로젝트에서는 myBatis Interface 방식으로의 개발을 고려중인데요,
이렇게 진행해도 기존방식으로 DAO 클래스 작성 시 반드시 삽입해야 하는 extends EgovAbstractDAO 구문이 사라지게 될텐데
당연히 문제가 없겠죠? (Impl 은 사용해야 하니 extends EgovAbstractServiceImpl 구문이 계속 들어갈 테구요)
그리고 한가지 더 궁금한 점은 myBatis Interface 방식으로 사용시 장점이 뭘까요?
기존 DAO 방식에 익숙한 End 개발자들에게 방식 변화에 대해 설득력 있는 내용을 제시해야 될텐데...
단순히 그냥 사용방식의 차이일 뿐이다. 라고 하기엔 하다못해 성능이 더 좋아진다. 라거나
Controller - Impl 사이에 사족처럼 보일 수도 있는 Interface를 굳이 사용하는 루즈 커플링 관점으로 보기에도
그냥 Interface 명 자체가 쿼리키가 되어 버리니 결합도가 낮아 보이지도 않는데 말이죠.
초기 설치 및 세팅 시에 제공되는 기본 샘플 모듈인데 조금 더 신경써서
소소한 버그없이 가급적인 소스 뎁스도 나름 권장하는 방식으로 잘 정리하여 제공하면 좋지 않을까 라는 생각이 듭니다.
스페이스 한칸 탭 한칸 잘못 들어가 있는 게 간간히 눈에 띄어 샘플 소스로서의 신뢰감이 좀 떨어져 보이곤 합니다.
물론, 추가적으로 별도로 제공되는 템플릿이나 지속적으로 제공되는 콤포넌트 등 참고하여 활용하고 있어 늘 감사드립니다.
추가적인 질문입니다.
이번에 진행되는 프로젝트에서는 myBatis Interface 방식으로의 개발을 고려중인데요,
이렇게 진행해도 기존방식으로 DAO 클래스 작성 시 반드시 삽입해야 하는 extends EgovAbstractDAO 구문이 사라지게 될텐데
당연히 문제가 없겠죠? (Impl 은 사용해야 하니 extends EgovAbstractServiceImpl 구문이 계속 들어갈 테구요)
그리고 한가지 더 궁금한 점은 myBatis Interface 방식으로 사용시 장점이 뭘까요?
기존 DAO 방식에 익숙한 End 개발자들에게 방식 변화에 대해 설득력 있는 내용을 제시해야 될텐데...
단순히 그냥 사용방식의 차이일 뿐이다. 라고 하기엔 하다못해 성능이 더 좋아진다. 라거나
Controller - Impl 사이에 사족처럼 보일 수도 있는 Interface를 굳이 사용하는 루즈 커플링 관점으로 보기에도
그냥 Interface 명 자체가 쿼리키가 되어 버리니 결합도가 낮아 보이지도 않는데 말이죠.
A
안녕하세요.
mybatis 사용 시 mapper interface가 반드시 필요한 경우는
mapper xml 파일을 어노테이션 방식으로 대체하고자 하는 경우입니다.
즉 mybatis @기능 사용을 위해 mapper interface가 필요한 것입니다.
물론 mybatis에서는 유연성을 제공하기 위해 mybatis @ + xml + mapper interface 혹은 xml + mapper interface 조합도 가능하도록 만들었습니다.
@ 어노테이션을 통해 mapper xml 설정을 대체하지 않더라도
mapper interface 사용 시 장점을 꼽자면,
DAO 클래스의 불필요한 코드와 작업을 줄여줄 수 있다는 점입니다.
일반적으로 DAO클래스에서는 statement id 호출 기능만 하는 경우가 많습니다.
예를 들어 void insert(vo) { insert("queryId", vo); } 이런식으로 구성됩니다.
ServiceImpl에서는 insert를 호출하면, DAO클래스 메서드 내부에서는 queryId를 파라미터로 또 다시 insert메서드를 호출하게 됩니다.
여기서 DAO의 핵심 역할이 queryId를 호출한다라는 것이라면, 굳이 insert, insert를 두번 호출하는 구조를 가질 필요가 없겠죠.
그러나 interface로 변경하게 되면 굳이 statement id를 호출하는 메서드 정의부를 작성할 필요가 없어지게 되고,
메서드명 자체가 각 statement id로 동작하기 때문에 코드 작성도 간편해지게 됩니다.
mapper interface 로 구현하시는 경우에는 extends 구문이 없습니다.
감사합니다.
mybatis 사용 시 mapper interface가 반드시 필요한 경우는
mapper xml 파일을 어노테이션 방식으로 대체하고자 하는 경우입니다.
즉 mybatis @기능 사용을 위해 mapper interface가 필요한 것입니다.
물론 mybatis에서는 유연성을 제공하기 위해 mybatis @ + xml + mapper interface 혹은 xml + mapper interface 조합도 가능하도록 만들었습니다.
@ 어노테이션을 통해 mapper xml 설정을 대체하지 않더라도
mapper interface 사용 시 장점을 꼽자면,
DAO 클래스의 불필요한 코드와 작업을 줄여줄 수 있다는 점입니다.
일반적으로 DAO클래스에서는 statement id 호출 기능만 하는 경우가 많습니다.
예를 들어 void insert(vo) { insert("queryId", vo); } 이런식으로 구성됩니다.
ServiceImpl에서는 insert를 호출하면, DAO클래스 메서드 내부에서는 queryId를 파라미터로 또 다시 insert메서드를 호출하게 됩니다.
여기서 DAO의 핵심 역할이 queryId를 호출한다라는 것이라면, 굳이 insert, insert를 두번 호출하는 구조를 가질 필요가 없겠죠.
그러나 interface로 변경하게 되면 굳이 statement id를 호출하는 메서드 정의부를 작성할 필요가 없어지게 되고,
메서드명 자체가 각 statement id로 동작하기 때문에 코드 작성도 간편해지게 됩니다.
mapper interface 로 구현하시는 경우에는 extends 구문이 없습니다.
감사합니다.