c#， Unity IoC:注册和解析泛型接口，良好的实践

我编写了通用接口，随着时间的推移，我开始经常使用它。我还想提供另一个通用接口，扩展现有接口。

现在，当我查看我的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, ...)
{
    // ...
}

我现在需要的是一个好的建议。也许我在这里滥用国际奥委会太多了。中型项目的最佳方法是什么?

---

我知道这个话题可能会以讨论而不是具体的答案结束，我为亲爱的StackOverflow道歉。

Eg configProvider.GetConfig<IWhateverConfig>();