C＃，Unity IoC：注册和解析通用接口，良好实践

Question

我编写了通用接口，随着时间的流逝，我开始经常使用它。 我也有想法实际上提供另一个通用接口，以扩展现有接口。

现在，当我查看我的Unity配置（此处的IoC框架不相关）时，它看起来像这样：

container.RegisterType<IConfigProvider<ICountryConfig>, CountryConfigProvider>();
container.RegisterType<IConfigProvider<ILanguageConfig>, LanguageConfigProvider>();

// IEnumerableConfigProvider<T> : IConfigProvider<IEnumerable<T>>
container.RegisterType<IEnumerableConfigProvider<ILocaleConfig>, LocaleConfigProvider>();

// ... repeat gazillion of times...

用作依赖项：

public LocaleResolver(IConfigProvider<ICountryConfig> countryConfigProvider, ...)
{
    // similar construct all over the place
}

其中ICountryConfig ， ILanguageConfig ，...是描述数据库实体的接口。 然后，提供者会小心地为相关组件提供正确的实体，因此对存储的访问将保留在自己的位置。

当我很少重构时就会出现问题。 我不小心使用了父接口，而不是继承了父接口。 当使用错误的接口类型时，它也可能非常脆弱。

这导致我（显而易见的）想法创建了另一层接口来封装具体用法。 那将解决上述问题，另一方面，对于每种可能的实现，我最终将拥有数万亿个空接口。

// ICountryConfigProvider : IConfigProvider<ICountryConfig>
container.RegisterType<ICountryConfigProvider, CountryConfigProvider>();

// ILanguageConfigProvider : IConfigProvider<ILanguageConfig>
container.RegisterType<ILanguageConfigProvider, LanguageConfigProvider>();

// ILocaleConfigProvider : IEnumerableConfigProvider<ILocaleConfig>
container.RegisterType<ILocaleConfigProvider, LocaleConfigProvider>();

而且使用更清洁：

public LocaleResolver(ICountryConfigProvider countryConfigProvider, ...)
{
    // ...
}

我现在正在寻找的是一个很好的建议。 也许我在这里滥用IoC太多了。 中型项目的最佳方法是什么？

---

我知道这个主题可能会以讨论而不是具体答案结尾，对于亲爱的StackOverflow，我深表歉意。

Answer 1

如果每个提供者都是不同的具体类型，则此方法（尽管带有空接口很冗长）仍然有效。 另一种不太冗长的解决方案是对配置访问进行一般化，因此，您只有一个配置“服务”，该服务返回许多特定配置blob中的任何一个。

Eg configProvider.GetConfig<IWhateverConfig>();

这样，您就不会在容器中充斥大量的提供程序，而这些提供程序实际上只是检索充满配置的某种类型的属性包。 您将注册一个配置提供程序，并且在幕后将配置类型映射到配置部分。 如果您公开了此映射功能，则可以在应用程序启动期间的任何时候以更模块化的方式注册config blob。