这是什么样的模式（'Provider'）？答案

【问题标题】：What kind of pattern is this ('Provider')?这是什么样的模式（'Provider'）？
【发布时间】：2014-10-14 07:13:36
【问题描述】：

在工作中，我们正在使用我在 GoF 书中没有真正找到的“模式”（但这可能是由于缺乏这方面的能力，我只是略读了模式）而且我仍然怀疑有点。

假设我们有一个多项目解决方案，其中包含一个项目DataAccess，该项目管理数据访问。然后通常我会看到它具有这样的结构：

Providers (Folder)
 - DataAccessProvider.cs

Interfaces (Folder)
 - IFileLoader.cs

Implementors (Folder)
 - FileLoader.cs

这里，FileLoader 将是接口IFileLoader 的internal 实现，提供程序如下所示：

public static class DataAccessProvider
{
  public static IFileLoader FileLoader
  {
    get { return new FileLoader(); }
  }
}

这是一种什么样的设计模式（如果有的话），除了掩盖IFileLoader接口的具体实现之外，它的真正用途是什么？

其次，这真的是“好风格”吗？例如，我想知道如果有很多这样的调用会发生什么

string content = DataAccessProvider.FileLoader.LoadContentFromFile("abc.txt");

无论何时使用它都会调用new FileLoader()。难道没有更优雅的方式来做类似的方法吗？

【问题讨论】：

【解决方案1】：

在此示例中，DataAccessProvider 是简单工厂方法（模式）的示例。通常你会有一个名为GetFileLoader() 或CreateFileLoader() 的方法，而不是属性版本，但结果是一样的。

返回IFileProvider 而不是FileProvider 的目的是为了依赖倒置，这样可以编写其他类型的FileProvider 并将它们注入应用程序，而无需返工或重新编译所有依赖的对象在IFileProvider 上。这不是关于掩饰。

如果关心创建了多少FileLoader 实例，则可以为该对象使用单例模式。但是，如果FileLoader 是轻量级对象，这通常不是问题，因为 CLR 垃圾收集器会自动为您处理这些问题。

【讨论】：

啊，谢谢！我想知道该模式是否总是有用，因为我们几乎在解决方案中的每个项目中都使用它，并且 90% 的时间只有（并且总是）只有一个实现各自的界面。此时，Provider 类成为方法的集合，以获取用于数据访问的不同接口的实现。如果你知道你永远不会换掉那个实现，这仍然是一种好习惯吗？
就技术而言，没有什么总是有用的。也就是说，使用接口通常是最佳实践，因为它可以为您带来很多好处（有助于依赖反转、单元测试、模拟、IoC 容器等）。如果您使用的是接口，那么使用 IoC 容器或工厂是最简单的。换出的能力是有用的，但对于存在价值来说不是必需的。
如果这是一个非常小的项目或个人项目，那么遵循这些模式可能不值得花时间和精力。