로깅 로직을 뷰 레이어 또는 서비스 레이어에 넣어야합니까?로깅 요청은 어디에 속합니까?
서비스 레이어가 여러 다른보기 (http, rpc 등)의 기본 레이어이기 때문에 더 이해가된다고 생각합니다. 로깅이 뷰 계층에서 수행 된 경우 각 다른 뷰에 대해 구현해야합니다.
반면에 모든 로깅 로직이 서비스 계층에있는 경우보기 수준에서 들어오는 요청과 실패를 기록 할 수 없습니다 (예 : JWT 인증 실패, 예를 들어 JWT 인증 실패, 요청이 서비스에 도달했습니다).
어디에서 로깅을해야합니까?
로깅은 여러 계층에서 발생한다는 것을 의미합니다 (인증과 유사 함). 예를 들어에서 로그인해야한다고 생각하면 프리젠 테이션 레이어 - 실제 구현과 독립적 인 공통 인터페이스를 사용하면됩니다. 예를 들어 Java에서는 기본 로거 구현의 외관 인 slf4j을 자주 사용합니다. 그러나, 일반적으로 그 로깅 외관을 사용하는 장소를 갖는 것이 좋습니다. 일반적으로 대부분 예외, 경고 등을 기록하므로 예외 처리를 담당하는 구성 요소에 로그합니다. Spring에서 종종 @ControllerAdvice 주석을 사용하여 이러한 구성 요소에 태그를 지정합니다 (모든 컨트롤러 호출을 차단하고 중앙에서 예외를 처리하는 옵션을 제공합니다). 다른 옵션은 모든 메소드/예외를 기록하기 위해 프로그래밍 (예 : AspectJ)을 AOP으로 사용하는 것입니다 (그러나 권고 된 조인 포인트의 런타임 중에 로그 할 메시지를 구성 할 수는 없습니다). 또한 코드를 사용하면 의미있는 이벤트를 발생시켜 다른 이벤트 (예 : 모든 이벤트 로깅을 담당하는 구성 요소)에서 처리하므로 이벤트는 매우 우아한 솔루션입니다.
따라서 모든 로깅을 모든 계층에서 수행 할 수 있지만 코드에서 모든 곳에서 logger.log() 호출을 분산시키지 말고 더 구조화 된 접근 방식 (중앙 예외 처리 클래스, AOP 또는 이벤트)을 대신 사용해야합니다.
질문 : 질문은 DDD와 관련이 없으므로 도메인 기반 디자인 태그를 제거해야한다고 생각합니다.
DDD 태그를 제거했습니다. –
왜 둘 다 있지 않습니까? 응용 프로그램 구성 설정에 따라 활성화 또는 비활성화 할 로깅이 결정됩니다. 괜찮은 로깅 프레임 워크는 그러한 구성 옵션을 갖게 될 것입니다. – David
저는 로깅 로직을 한 곳에 집중시키는 아이디어와 비슷하다고 생각합니다. 또한 로깅이 게이트웨이 서비스로 구현되는 경우보기에는 (이상적으로)보기가 있어야합니다. 뷰 계층에 로깅을 시작하려면이 제 3 자 로깅 서버에 대한 지식이 있어야하며 서버와 통신하는 방법을 알아야합니다. – user7467314
응용 프로그램 계층에는 해당 종속성에 대한 지식이 전혀 필요하지 않습니다. 세부 사항은 기술마다 다를 수 있지만 일반적으로 모든 구성 요소가 기록 할 수있는 내 도메인에 로깅 인터페이스가 있습니다. 내 의존성 반전은 인터페이스를 사용하는 특정 구성 요소에 알려지지 않은 해당 인터페이스의 구현을 제공합니다. 나는 당신이 임의로 단 하나의 장소에 로그인하기를 원한다면 그 장소를 골라야한다고 생각합니다. 하지만 애플리케이션 코드와 서비스 코드는 매우 다른 데이터를 처리하고 작동하므로 개인적으로 두 가지 옵션을 모두 기록해야합니다. – David