DAO(Repository)에서 발생한 예외처리 질문
이성현(kemuel)
의문입니다.
아래 코드는 저 나름대로 예외 처리를 한 코드 입니다.
MemberDAO에서 중복 예외를 발생 시켜 Controller에서 처리를 합니다.
DuplicateMemberException는 DuplicateKeyException을 의미 있는 uncheck
exception 으로 전환 하기 위해 만든 Exception입니다.
먼저 Member가 중복인지 아닌지 select로 검사 할 수 있지만 저는 중복을 예외를 처리하려고 했습니다.
즉, 중복 Member는 존재하지 않는다는 비즈니스 로직을 예외로 처리하는 것입니다.
궁금한 점은 controller에서 비지니스 로직적인 것을 controller에서 예외처리를 해야 하는지
MemberService에서 또 try catch문으로 예외를 잡아서 처리하여 의미 있는 예외를 controller로
throws 하거나
아니면 return value를 true/fase 로 변경해야 하는 건지 궁금합니다.
제 생각은 controller에서 예외처리를 하면 MemberService 쪽이 깔끔한(나이스)한 코드가 되어 좋아 보입니다.
다른 예외 전략(처리)가 있다면 답변 부탁 드립니다.
============== Controller 에서 예외처리 ====================
========== MemberDAO =============================
@Override
public void insertMember(Member member) throws
DuplicateMemberException {
try {
sqlMapClientTemplate.insert("member.insertMember", member);
} catch (DuplicateKeyException e) {
throw new DuplicateMemberException(e);
}
}
========== MemberService =============================
@Override
public void registMember(Member member) {
memberDAO.insertMember(member);
}
========== MemberController =============================
@RequestMapping("/member/registmember.do")
public String registMember(Member member) {
try {
memberService.registMember(member);
return "main"
} catch (DuplicateMemberException e) {
return "/member/viewregistmemberform";
}
}
============== service에서 예외처리 ====================
========== MemberService =============================
@Override
public boolean registMember(Member member) {
try {
memberDAO.insertMember(member);
return true;
} catch (DuplicateMemberException e) {
return false
}
}
========== MemberController =============================
@RequestMapping("/member/registmember.do")
public String registMember(Member member) {
if(memberService.registMember(member) {
return "main";
} else {
return "viewregistmemberform";
}
}
강동욱
이성현(kemuel)
Validation은 값(value)검증만 하는 것이라 생각했는데
Exception 처리도 하는거 군요.
view(jsp)와 controller 사이에 값 검증만 해봐서 확 와닿지 않아서 그런데
Validator로 Exception 처리하는 참조 사이트든가 처리하는 흐름만 좀 알려주 주시면 정말 감사 하겠습니다.
Sungchul Park
이 경우에는 컨터롤러에서 예외를 처리하는 쪽이 적절하다고 봅니다.
MemberDAO에서는 DB Access 관련 예외인 DuplicateKeyException를 도메인 예
외인 DuplicateMemberException로 잘 바꿔서 서비스에서 넘겼는데
DuplicateKeyException 자체가 이미 구현 기술 의존성을 숨긴 추상화한 된 예
외이나 도메인의 스프링 의존성도 줄인다는 관점에서는 의미 있는 작업 같습니다.
MemberService에서 메서드 시그니처에 throws DuplicateMemberException를 추
가해서 명문화했으면 좋았겠습니다.
MemberController의 try-catch는 프레임워크 차원에서도 처리할 수 있지만 공
통사항이 아니라 특정 업무의 워크플로에 해당하므로 컨트롤러에서 흐름을 제
어하는 편이 좋다고 생각합니다.
저는 왜 두 경우를 두고 고민하시는지 이해하지 못하겠네요. 서비스에서 처리
하면 어떤 이득이 있는 거죠? 코드량이 늘었을 뿐 아니라 서비스의 반환값이
어떤 의미인지 알려면 javadoc 같은 문서를 봐야만 분명해지는 번거로움까지
생겼는데요.
이상용
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+unsubscribe@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
Sungchul Park
> 되도록이면 Controller에서는 Exception 처리를 하지 않는 편이 좋다고 봅니다.
관련 자료라도 알려주시면 고맙겠습니다.
> 제 경우에는
> View - Controller - Validation Logic- Business Logic - DAO
>
Validation Logic이 하는 역할은 무엇인가요?
이상용
이성현(kemuel)
Business Logic이 들어 가는게 아닌가해서 그렇게 생각 했습니다.
Business Logic이 변경되면 Controller가 변경되는거 아닌가 해서요.
Controller는 DispatcherServlet가 Service에 맵핑하는 중간 역할이라 생각 하고 있습니다.
2번째 방법은 true/false 합니다.
만약 Business 로직이 Member 중복을 허용으로 바뀌면 Controller는 변경이 없을수 있겠죠(?)
Exceptoin 처리 전략을 프레임 워크로 해결 할 수 있다면 if else 또한 사라질 수 있지 않을 까 했습니다.
이 방법은 저의 개인적인 생각입니다. 저두 지금 현재 구글링 하며 자료들을 찾고 있는 중이에요..
Jihwan Kim
CustomSimpleMappingExceptionResolver 를 구현하여 예외처리를 한곳으로 모았습니다.
예외는 예외상황별로 runtime 익셉션을 상속받아 정의하였구요.
헤더타입(Accept)에 따라 결과(예외코드 및 오류 메시지)처리를 하였습니다. (html, json, xml)
간혹 라이브러리에서 checked exception을 발생하는 메소드 같은 경우는 wrapping하여 runtime익셉션을
발생하도록 하였습니다.
위구조에서는 Controller에서는 try{} catch{} 문이 필요없구요. 서비스나 다오 레이어에서는 상황에 따라 있을
수 있지만 public method에서는 가독성을 위해서 지양하고 있습니다.
물론 예외가 아닌 정상플로우로 진행시켜야 하는 경우에는 컨트롤러에서 try catch가 필요할수도있겠으나 아직까지 그런 경우는
없었습니다.(이 경우는 controller 보다는 서비스 레이어에서 처리하는게 낫지 않을까 생각합니다.
2012년 3월 19일 오후 3:39, 이성현(kemuel) <kemu...@gmail.com>님의 말:
> --
> Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
Jihwan Kim
저도 비즈니스 로직을 어디에 두어야 하나, (컨트롤러?, 서비스?, 컨트롤러 + 서비스?) 고민이 많았습니다.
현재는 사이트 성격에 따라 좀 달라질수 있다고 생각하여 그부분에서는 자유도를 두고 있습니다.
하지만 동일한 사이트에서는 일관성있어야 겠죠.
2012년 3월 20일 오전 8:09, Jihwan Kim <jhki...@gmail.com>님의 말:
이재일
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+unsubscribe@googlegroups.com로 이메일을 보내주세요.
고종봉
@RequestMapping("/member/registmember.do")
public String registMember(Member member) {
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
