0
로깅 프레임 워크 (log4net, NLog 등)를 살펴볼 때, 대부분은 매우 기본적인 인터페이스를 따르고 있습니다. Common.Logging 인터페이스는 로깅 프레임 워크와 코드간에 어댑터 및 기타 등을 사용하여 추상화 및 단일 계약을 생성하는 데 유용합니다.래핑 로깅 프레임 워크
애플리케이션 로깅에 대한void Trace(object message);
void Debug(object message);
void Info(object message);
void Warn(object message);
void Error(object message);
void Fatal(object message);
, 우리가 뭔가 더 표현 및 명시 적 싶지 않을 것이다 : Common.Logging는 다음과 같은 인터페이스 (아래 요약)를 제공?
예를 들어 더 많은 필드를 기록 할 수 있습니다. 아마도 "방법"또는 "컨텍스트"필드가 필요합니까? 어쩌면 나는이 방법의 명명 규칙을 정말로 좋아하지 않을 것입니다. 그들은 동사가 아닙니다. 우리 표준을 위반하는 것. 이것은 또한 너무 많은 유연성을 제공합니다 - 각 개발자가 로깅을 어떻게 처리할지 알고 있습니다. 이러한 이유로
, 나는 더 명시 적으로 뭔가Common.Logging 포장 안넘어 :
void LogTrace(string context, string message, string parameters);
void LogDebug(string context, string message, string parameters);
void LogInfo(string context, string message, string parameters);
void LogWarning(string context, string message, string parameters);
void LogError(string context, string message, string parameters);
void LogError(string context, string message, string parameters, Exception ex);
void LogFatal(string context, string message, string parameters);
void LogFatal(string context, string message, string parameters, Exception ex);
이는 것이 좋습니다 이러한 접근 방식에 대한 단점이있다?
나는 이점을 보지 못했다. 당신이 지정한 것을 추상화하지 않습니다. 객체 메시지가있는 메소드는 가능한 한 추상적입니다. 물론 당신은 그 위에 API를 놓아서 타입 - 안전한 API를 얻을 수있다. 메시지가 문자열로 직렬화 될 것이므로 명시적인 매개 변수가 필요한 이유는 무엇입니까? 익명 유형 또는 "LogMessageType"을 사용하십시오. 로깅을 위해 새로운 API를 작성하십시오. 그러나 애플리케이션별로 다르며 "추상적"이 아닙니다. 다음을보십시오 : https://github.com/damianh/LibLog –
@StefanOssendorf : 사과. 업데이트 된 질문. 나는 본질적으로 포장하지 않고 포장하고 싶다. – davenewza