대부분의 종속성 삽입 프레임 워크는 다양한 매개 변수로 주입되는 구성 요소를 초기화하는 것을 지원합니다. 일반적으로 XML 구성 파일에서 읽습니다.사용자 설정에 대한 종속성 주입 매개 변수입니까?
이것은 서버 이름이나 구성 요소가 필요로하는 파일 경로와 같은 설정을 저장하는 매우 편리한 장소처럼 보입니다. 그러나 적절한 방법인가, 아니면 설정을위한 별도의 구성 파일을 갖는 것이 더 합리적입니까? 그리고 사용자가 UI를 통해 설정을 변경할 수 있어야하는지 여부는 중요합니다.
IMHO, 상식의 문제입니다. 보통, 나는 같은 설정 파일에 모든 것을 보관하지만, 다른 섹션에있다. 설정 파일을 너무 많이 사용하면 팀의 새로운 사용자가 코드를 이해하는 것이 더 어려워집니다. 그러나 파일이 너무 커지면 파일을 분리해도 괜찮은 것 같습니다.
UI 설정에 대해서는 개발자가 대부분의 선택을해야하지만 구성을위한 공간을 열어야한다고 생각합니다. 지금 당장 링크가 없지만 잼을 파는 가게의 흥미로운 이야기가 있습니다. 그들은 고객이 토스트로 잼을 맛보게 할 것이고, 이는 판매량을 크게 늘리게된다. (고객은 자신이 사는 물건의 품질을 알 것이다). 처음에는 많은 잼 옵션 (3 개)이 없었으며 성공했습니다. 너무 많은 옵션 (예 : 20 개)이 있었을 때 고객은 많은 옵션을 조금 혼란스러워했습니다.
구성 가능성을 줄이는 또 다른 이유는 개발 시간을 줄이는 것입니다. 책 Getting real (나는 이것을 추천한다)을 읽으면, 그들은 적은 시간을 할애해야한다고 말한다. 10 장에서, 그들이 말하는 :
* Less software is easier to manage.
* Less software reduces your codebase and that means
* Less maintenance busywork (and a happier staff).
* Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code. Less software results in fewer bugs.
* Less software means less support.
그래서 이럴 사용자가 대부분을 변경하고 이러한 구성하고 싶습니다 어떤 설정 알아보십시오. 또한 시스템이 이미 프로덕션 환경에 있고 느리게 계속 성장한다면 시간이 지남에 따라 구성을 위해 더 많은 공간을 열 수 있다고 생각합니다. 예를 들어 Gmail에는 구성 옵션이 많지 않지만 사용자가 익숙해지면서 Google 실험실의 테마 및 기타 기능을 변경하는 것과 같은 사용자 옵션을 만들기 시작했습니다. 이렇게하면 학습 곡선이 사용자를 "해가되지 않습니다".
희망이 있습니다.
다른 환경에서 어떤 설정을 수정해야하는지 명확히하기 위해 설정을 별도의 파일에 저장하는 것이 좋습니다. 또한 의존성 삽입 프레임 워크 (예 : 시스템 관리자, 최종 사용자)에게 익숙하지 않은 사용자가 설정을 수정하기가 더 쉽습니다.
매우 작은 응용 프로그램이며 개발자가 설정을 변경하는 경우 DI 구성에서 설정을 유지할 수 있습니다.