ArgumentResolver는 Service를 가져야 할까 Dao를 가져야 할까?

지난 블로그 글 [Spring] ArgumentResolver로 검증 기능 통합하기 와 이어지는 주제입니다.

[Spring] ArgumentResolver로 검증 기능 통합하기

 

이전에 진행한 장바구니 미션에서 ArgumentResolver를 통해 여러 컨트롤러에서 공통으로 필요한 회원 확인 로직에 대한 중복 제거 작업을 진행했다.

그러던 중, ArgumentResolver에서 Service를 참조할지 dao를 참조할지, 아니면 둘 다 참조하면 안되는지에 대해 의문이 들었고, 리뷰어에게 다음과 같은 답변이 왔다.

의견 1: ArgumentResolver는 Controller 계층이다

ArgumentResolver의 동작 과정과 계층형 아키택쳐 구조의 입장으로 바라본 의견이었다.

ArgumentResolver는 DispatherServlet의 HandlerMapping 과정에서 수행되기 때문에 Controller의 계층에 속하고, 따라서 Controller - Service - Dao의 계층 구조를 지키기 위해서는 Dao보다 Service를 참조하는게 바람직하다는 뜻이었다.

 

하지만 다른 크루들의 리뷰를 보면서 또 다른 관점에 대해서도 생각해 보게 되었다.

의견 2: ArgumentResolver의 역할에 대해 고민해 보아야 한다.

ArgumentResolver가 단순히 전달 받는 인자값을 객체로 바인딩 해주는 역할을 위해 만들어진 개념이고, 따라서 굳이 그 안에서 비즈니스 로직에 해당하는 작업을 수행하는 것은 옳지 않다는 의견이었다.

 

거기에다 또 다른 크루의 리뷰에는 종합 선물세트 급의 코멘트가 적혀 있었다.

레전드

CCC?(한국대학생선교회 아님)

그리고 CCC라는 키워드에 대해서도 알게 되었다.

이는 관점 지향 프로그래밍(AOP)에 나오는 개념으로, 하나의 부가 기능이 여러 곳에서 동일하게 사용되는 횡단 관심사(Cross Cutting Concerns)의 개념이었다.

 

애플리케이션을 바라보는 관점을 기능 단위에서 횡단 관심사 관점으로 바라보고, 이러한 기능을 합해서 하나의 모듈, aspect의 개념으로 정의한다.

해당 개념은 OOP를 대체하기 보다는 동일한 관심사를 깔끔하게 모아 구성하기 위한 OOP의 부족한 부분을 보조하는 목적이라고 한다.

 

요점은 하나의 기능이 여러 계층에서 동일하게 사용된다는 데 있었다.

CCC를 설명하는 다양한 그림들

 

확실히 ArgumentResolver가 나오게 된 배경인 AOP의 관점에서 바라본다면 계층에 상관없이 동일한 관심사에 대한 중복 로직 제거를 위한 기능이라는 생각이 들었다. 

 

하지만 리뷰어들 사이에서도 서로 다른 의견이 갈리는 것으로 보아 가장 중요한건 어떤식으로 진행하든 해당 방식에 대한 근거를 두고 작성할 필요가 있을 것 같다.!