到目前为止，在我所有的项目中，我一直使用单例模式来访问整个应用程序中的应用程序配置。最近，我看到很多文章都打算不使用单例模式，因为这种模式不会提高可测试性，而且会隐藏Component依赖项。我的问题是存储应用程序配置的最佳方法是什么，它可以在整个应用程序中轻松访问而无需在整个应用程序中传递配置对象？。
预先感谢
马杜
我认为应用程序配置是Singleton模式的出色使用。我倾向于自己使用它，以防止每次我要访问它时都必须重新读取配置，因为我希望对配置进行强类型化（即不必每次都转换非字符串值）。我通常在Singleton中内置一些后门方法以支持可测试性-即能够注入XML配置以便可以在测试中进行设置以及销毁Singleton以便在需要时重新创建的能力。通常，这些是我通过反射访问的私有方法，因此它们对公共接口是隐藏的。
EDIT我们生活和学习。虽然我认为应用程序配置是使用Singleton的少数几个地方之一，但是我不再这样做了。通常，现在，我将使用配置属性的静态Lazy<T>备用字段创建接口和标准类实现。这使我对每个属性都具有“初始化一次”的行为，并且具有更好的可测性设计。
使用依赖注入将单个配置对象注入需要它的任何类中。这样，您可以将模拟配置用于测试或任何您想要的...您没有明确地出去并获得需要使用配置文件初始化的内容。使用依赖项注入，您也不会传递对象。
对于这种特定情况，我将创建一个配置对象，并将其传递给需要它的人。
因为它是配置，所以仅应在应用程序的某些部分中使用，而不必是无所不在。
但是，如果您在使用它们时没有遇到问题，并且不想对其进行如此艰苦的测试，则应该像今天一样继续前进。
阅读有关为什么认为它们有害的讨论。我认为，大多数问题是由单身人士占用大量资源造成的。
对于应用程序配置，我认为将其保持原样是安全的。
单例模式似乎是要走的路。这是我写的Setting class，很适合我。
这里是使用Setting完成的示例
[如果任何组件依赖于可以在运行时更改的配置（例如，对小部件的主题支持），则需要提供一些回调或信令机制来通知已更改的配置。因此，在创建时仅将所需的参数传递给组件是不够的（例如颜色）。您还需要提供从组件内部对配置的访问（将完整的配置传递给组件），或使组件工厂存储对配置及其所有已创建组件的引用，以便最终可以应用更改。
前者有一个很大的缺点，即它可能使构造函数混乱或破坏接口，尽管它可能是原型制作最快的方法。如果考虑“ Demeter法则”，这是一个很大的否定，因为它违反了封装。后者的优点是组件保留其特定接口，使组件仅在需要的地方使用它们，并且作为奖励，您可以在工厂（工厂）中进行重构。从长远来看，代码维护可能会受益于工厂模式。
而且，即使工厂是一个单例，它也可能会比配置单例所用的地方少得多。