2013-02-19 3 views
0

우리 팀은 WCF 서비스에 대한 예외 처리 및 로깅 구현을 자동화하는 라이브러리를 만들었습니다. 개발자는이 라이브러리를 사용하여 사용자 지정 특성을 사용하여 서비스를 꾸밀뿐 아니라 간단한 구성 파일 항목을 설정하고 일반 예외 처리 및 로깅 메커니즘을 이미 활용할 수 있습니다..NET의 특성/장식자를위한 IOC

다음은 라이브러리를 사용하는 방법의 예 :

[ErrorHandlingBehavior (LogWriterOption.EmailLogWriter, LogWriterOption.SQLLogWriter)] 
public class SampleService : ISampleService 
{ 
    public string GetData(int value) 
    { 
     throw new DivideByZeroException(); 
     //return string.Format("You entered: {0}", value); 
    } 
} 

ErrorHandlingBehavior 클래스는 로그 위치를 파악하는 매개 변수의 LogWriterOption 열거 형에 소요 로거 객체를 사용합니다.

원래 의도는 개발자가 자신의 로깅 메커니즘을 지정하고 ErrorHandlingBehavior에 제공하여 Logger 클래스에서 솔루션의 종속성을 제거합니다 (대신 ILogger를 구현하는 모든 클래스를 사용함). 그러나, 아래의 방법으로 속성을 지정하면 오류가 발생합니다 :

[ErrorHandlingBehavior (new Logger (new HashSet<LogWriterOptions> 

          {LogWriterOption.EmailLogWriter, LogWriterOption.SQLLogWriter}))] 

속성을 지정할 때 우리는 무엇을 인스턴스화 할 수 없습니다 것, 따라서 우리는 지금 사용자가 자신의 로깅 메커니즘을 지정할 수 없습니다.

누구든지이 문제를 해결할 방법을 알고 있습니까? depenendency를 하드 와이어하는 대신 ILogger를 구현하는 클래스의 인스턴스를 속성에 어떻게 공급할 수 있습니까?

답변

1

로깅 예외 처리 동작도 기록했습니다. 이와 같은 상황에서 나는 항상 다음과 같이 질문했습니다.

log4net은 무엇을할까요?

LogWriterOptions이 log4net appender로 해석되는 것으로 보입니다. 어 펜더는 환경에 따라 요구 사항이 달라지기 때문에 xml 구성을 통해 일반적으로 가장 잘 수행됩니다. (로깅에 상응하는 것은 WCF 클라이언트 바인딩을 코드에 넣지 마십시오.) 즉, 로컬에서 개발할 때 전자 메일을 보내지 말고 로컬 텍스트 파일로 출력하십시오. QA에서 실행 중일 때 : DB 로의 출력은 테스터와 함께 이메일을 보내지 않고 목적에 부합하지 않습니다. 생산 단계에서 : 완전히 다른 것을하십시오. 위로 질문에

Log4net appenders support all these types of post compile changes (and more). :

당신의 접근 방식에서
  • , 내가 EmailLogWriter 및 SQLLogWritter 결과 구성 행동을 보일 것 "StandardLogging"와 같은 문자열로 ErrorHandlingBehavior에게 행동의 이름을 전달 할 사용중인 .
  • 로깅 프레임 워크에서 일반적으로 사용되는 다른 방법은 pass the type of the class being logged입니다. 해당 유형을 명시 적으로 구성하지 않으면 기본 appender를 가져옵니다.

참고이 구성 방법은 전체 응용 프로그램에 대한

  1. 중앙 집중식 로깅 출력 옵션의 추가 혜택이 있는지 확인합니다. 표준을 변경하면 많은 클래스 파일을 업데이트 할 필요가 없습니다.
  2. 다른 로그 코드 옵션을 사용하여 어떤 로그 기록기 옵션을 표준화하고 있습니까? 코드 검토 회의에서 "표준 로깅 출력을 사용하고 있습니까?"라는 메시지를 확인하십시오.

당신 "을 유지 간단한"주석에 응답하여 업데이트 :

간단 유지하는 경우가 목표입니다, 나는 당신의 행동의 생성자에 패스 아무 말도하지 않을 것이다. 대신 모든 log4net 구성 정보를 자체 log4net.config 파일에 저장하고이를 소스 제어의 공통 로깅 라이브러리의 일부로 저장하십시오. 그런 다음 새 프로젝트 (또는 하위 개발 업체)에 app.config에

<configuration> 
    <log4net configSource="log4net.config" /> 
</configuration> 

을 추가하기 만하면됩니다. 이 방법의 보너스는 빌드 프로세스의 일부로 다른 환경에 배포하기 위해 서로 다른 log4net.config 파일을 정의한다는 것입니다.

+0

우리는 log4net도 사용했지만, 우리가 원했던 것은 중학교의 devs가 사용하기에는 조금 우호적 인 것이 었습니다. log4net의 문제점은 부피가 큰 구성 섹션이 있다는 것입니다. 이는 많은 사용자 지정 작업을 수행하고자하는 숙련 된 개발자에게는 유용하지만 방금 시작한 경우 구현하는 것은 귀찮습니다. 우리의 아이디어는 매우 간단한 설정 파일로 dll을 참조함으로써 바로 사용할 수있는 것이었다. 로깅 또는 WCF 오류 처리에 대한 지식이 부족한 주니어 개발자는이 DLL을 참조 할 수 있으며 오류 메시지는 로깅 및 처리 시스템에 기본적인 오류가 있습니다. –

+0

@JericCantos - 내 업데이트를 참조하십시오. – ErnieL

0

공장 패턴을 사용할 수 있습니다. 개발자가 ILogger 인스턴스를 제공하는 데 사용됩니다 유형을 지정 되세요 :

public interface ILoggerFactory 
{ 
    ILogger GetLogger(); 
} 

다음 사용자 정의 속성 내에서 먼저를 얻을 수 :

[ErrorHandlingBehavior(LoggerFactoryType = "FooBar.MyLoggerFactory")] 

이 유형은 당신의 인터페이스를 구현할 수 팩토리 유형을 Type.GetType 메소드를 사용하여 ILoggerFactory 인터페이스를 구현하는지 확인하고 Activator.CreateInstance 메소드를 사용하여 팩토리를 인스턴스화 한 다음 마지막으로 해당 인스턴스에서 GetLogger 메소드를 호출하십시오.

+0

답변 해 주셔서 감사합니다. 따라서이 시나리오에서는 개발자가 만든 원래 로거에 대한 로깅 옵션을 어디에서 지정할 수 있습니까? 그것은 GetLogger 방법에도 포함됩니까? 또한, 본질적으로 모든 유형의 로거에 대해 하나의 LoggerFactory가 될 것인가? 예를 들어 개발자가 원래 라이브러리에서 제공 한 로거와 다른 로거를 사용하려는 경우 자신의 로거 팩토리를 코딩해야 할 필요가 있습니까? –