2014-06-11 2 views
6

생산 코드에서 container.Verify()으로 전화하는 것이 가장 좋습니다. 나는 이동의 생각 : 나는 일반적인 합의가/가장 좋은 방법이 무엇인지에 관해서는 그냥 궁금 변화를 만들 수있는 진짜 이유가없는생산 코드의 단순 인젝터 확인()

#IF Debug 
    container.Verify(); 
#ENDIF 

.

답변

7

Verify을 호출하는 것이 유용한 지 여부는 논쟁의 여지가 있습니다. 2011 년에 Mark Seemannsuch a method is close to worthless으로 생각했습니다. 제 의견으로는 Verify을 호출 할 때 실제 가치가 있다는 것입니다. 그러나 Mark의 정서를 이해하고 Verify 그 자체로 호출하는 것이 일반적으로 충분하지 않음에 동의합니다. 그렇기 때문에 Simple Injector wiki의 Verifying the container’s configuration에 DI 구성을 검증 가능하게 유지하는 것에 대한 명확한 지침이있는 것입니다.

그러나 Simple Injector를 사용하면 Verify이 개체 그래프를 만들 수 있는지 여부를 테스트하는 것 이상을 수행합니다. Verify으로 전화하면 Simple Injector의 Diagnostic Services이 시작되어 매우 흔하지 만 때로는 구성 오류 (Mark가 해당 기사를 작성한 시간 동안 사용할 수 없었던 기능)를 찾아 내기도합니다.

일반적으로 가능한 한 내 생산 코드에서 container.Verify으로 전화하는 것이 좋습니다. 디버깅 및 릴리스 빌드, 준비 환경 및 프로덕션 모두에서 항상 시작시 호출하십시오.

응용 프로그램이 커질수록 시작 중에 container.Verify에 전화하는 데 시간이 많이 걸립니다. 일부 유형의 응용 프로그램은 다른 응용 프로그램보다 더 민감합니다. 서버 응용 프로그램의 경우 일반적으로 시작 시간을 늘리는 것이 좋지만 데스크톱 및 휴대 전화 응용 프로그램은 더 빨리 시작해야합니다.

Verify에 대한 호출에 너무 많은 시간이 걸리는 경우 - Verify에 대한 호출을 제거해야하지만 적어도 적어도 container.Verify을 호출하는 단위/통합 테스트가 있어야합니다. 나는 당신의 질문에서했던 것처럼 컴파일러 지시어에 Verify을 배치하는 데 아무런 문제가 없다. 그러나 IMO를 사용하면 가능한 한 오랫동안 시작 경로에 Verify에 대한 호출 제거를 연기해야한다.

+0

응답 해 주셔서 감사합니다. Steven. 위와 같은 작업을 수행하려면 통합/유닛 테스트를 위해 계획을 유지해야하므로 사전 배포를 어떤 형태로 실행하는 것이 보장됩니다. – Tris