스프링 MVC 설계 질문 드립니다.

Question

스프링 MVC 패턴으로 개발을 하고 있는데요, 서비스 레이어는 절대 같은, 또는 상위의 레이어에 의존하지 않도록 하고 있고(당연하지만 서비스는 다른 서비스나 컨트롤러를 의존하지 않는다는 얘기입니다)다른 도메인에 하위 레이어에 대한 의존 역시 지양하고 있습니다(A 서비스는 가급적 A 레포지토리에만 의존하도록 한다는 얘기입니다).하지만 아시다시피 모든 응답이 특정 도메인 하나에 대한 조회만 필요로 하지는 않죠.결국 하나의 컨트롤러에서 여러 서비스를 호출하고 이 정보들을 취합해야 하는데그 결과 이런 흐름을 갖게 됩니다.컨트롤러 메서드(클라이언트 요청) { 요청에 자체에 대한 유효성 검증 A서비스 호출 후 반환 값 획득 획득한 반환 값을 B서비스에 매개변수로 전달하여 호출 C서비스에 대해서도 동일한 호출 A, B, C의 결과를 취합하여 응답 구성 후 클라이언트에게 반환 }이렇다보니 컨트롤러의 메서드 분량이 꽤나 많아지고단순히 빌더로 취합하는 과정 외에도 몇몇 if 분기가 존재해서작성하고보니 컨트롤러가 여러 서비스 로직에 의존하고 있고, 비즈니스 로직을 분담하고 있다는 생각이 듭니다..하지만 서비스나 레포지토리들이 자신의 도메인에 대해서만 역할을 확실히 분담하게 하려면컨트롤러에서의 취합 과정이 불가피할 것 같은데크게 신경쓰지 않아도 괜찮을까요?

장독깨기 · Accepted Answer

서비스 보는 관점을 바꿔보세요.사용자가 뭔가 요청을 합니다. 조회일 수도 입력일 수도 있죠.이 조회 및 입력은 여러 테이블과 당연히 관련이 있을 수 있고, 대부분이 그렇습니다.여기서 서비스는 사용자가 요청하는 단위입니다.특정 정보를 조회하는 것이 하나의 서비스고, 이 서비스는 여러 테이블에 걸쳐있는 데이터를 취합해서 보내는거죠.특정 정보를 입력하는 것, 역시 하나의 서비스고, 여러 테이블에 입력할 수 있으며,이는 하나의 트랜잭션으로 관리되어야 합니다.지금 글쓴이는 서비스를 모듈로 보고 있습니다.여러 모듈을 조합해서 하나의 서비스로 만들 수는 있지만, 모듈이 서비스는 아닙니다.서비스 레이어는 절대 같은, 또는 상위의 레이어에 의존하지 않도록 하고 있고(당연하지만 서비스는 다른 서비스나 컨트롤러를 의존하지 않는다는 얘기입니다)일단, 서비스는 컨트롤러에 의존할 수 없습니다. 컨트롤러가 서비스를 호출하지 그 역이 아니잖아요.그리고, 앞서 말씀드린 서비스 관점에서 보면, 서비스에서 다른 서비스를 호출 할 일이 없습니다.그니까, 저 얘기는 어찌보면 너무 당연하고 자연스럽게 그렇게 됩니다.다른 도메인에 하위 레이어에 대한 의존 역시 지양하고 있습니다(A 서비스는 가급적 A 레포지토리에만 의존하도록 한다는 얘기입니다).어디서 이런 말이 나왔는지 모르겠지만, 잘 못 이해 했거나, 잘 못 된 얘기입니다.참고하시구요, 서비스가 무엇일까 에 대해 생각을 한 번 해보는 것이 좋겠습니다. :)

greatbk · Answer

컨트롤러에서는 비지니스 로직을 배제하는것이 맞습니다. 비지니스 로직이 복잡해지더라도 서비스에서 처리해야 합니다.

greatbk · Answer

그리고 뭔가 잘못된 방향으로 가고계신듯 한데..서비스에서 서비스를 호출하는 흐름이 자연스러운거예요.. 이걸 배재한다는것 자체가 잘 이해가 안되네요

스프링 MVC 설계 질문 드립니다.

3개의 답변

#mvc 목록