어떻게 우리의 솔루션을 참조 ConfigurationManater.AppSettings [ ""] (Web.config의에서) appSettings는을 얻을 전반에 걸쳐 우리의 CM.AppSettings 참조

Question

ASP.NET 3.5

클래스를 향상시킬 수 있습니다.

우리는 우리가 그것에 만족하지 않기로 결정했습니다. 사람들은 코드에서 appSetting 키 이름을 잘못 입력하여 (잘 컴파일 됨) 사용법을 추적하기가 번거로 웠습니다. 그런 다음 동일한 appSettings를 전체적으로 참조 할 때 코드베이스 전체에 중복 된 문자열이 있습니다.

그래서 우리는 한 클래스 만이 ConfigurationManager를 참조하도록 허용하고 나머지 솔루션은 특정 appSetting 값이 필요할 때 해당 클래스를 참조 할 것이라고 결정했습니다. ConfigurationManater.AppSettings [ ""]은 정적 이었기 때문에 우리는 하나의 Settings 클래스에서 많은 정적 인 읽기 전용 속성을 노출했습니다.

public class Settings { 
    public static string Foo { 
     get { 
      return ConfigurationManager.AppSettings["Foo"]; 
     } 
    } 
} 

우리가 테스트에서 설정을 조롱 할 때까지는 꽤 잘 돌아갔다. 우리는 조롱을 가능하게하는 인터페이스를 만들었습니다 (어떤 종류의 실수였습니까?).

public interface ISettings { 
    string Foo { 
     get; 
     set; 
    } 

} 

public class Settings : ISettings { 
    public string Foo { 
     get { 
      return ConfigurationManager.AppSettings["Foo"]; 
     } 
    } 
} 

그리고 지금 우리가 설정 값을 사용하는 개체의 종속성으로 ISettings 인스턴스를 주입하고 (클래스/인터페이스는 모두가 문제없이 참조 할 수있는 프로젝트에있다).

기존 인스턴스 (예 : Global.asax)를 삽입 할 수없는 곳에서는 정적 필드에 새 인스턴스를 만듭니다.

이 모든 것을 감안할 때 우리는 무엇을 바꿀 것을 권하고 싶습니까? 그 이유는 무엇입니까?

Answer 1

인터페이스를 사용하여 구성을 나타내는 것이 좋습니다. 그러나 당신의 구현은 약간 벗어난 것처럼 보입니다.

Joshua Flanagan은 특정 구성 섹션을 코드에 삽입 할 수있는 방식으로 애플리케이션 구성 코드를 작성하는 방법에 대해 썼습니다. 이것은 좋은 생각입니다. 실제로 코드는 구성 뒤에있는 세부 사항을 걱정하지 않도록 코드를 분리합니다. Have a read.

저는 이것이 당신이 가지고있는 문제를 해결할 것이라고 생각합니다. 테스트 가능성.