Ninject 约定泛型接口具有与具体类不同数量的参数答案

【问题标题】：Ninject conventions generic interface having different number of arguments than concrete classNinject 约定泛型接口具有与具体类不同数量的参数
【发布时间】：2013-01-27 14:36:25
【问题描述】：

有没有办法使用 NInject 约定来绑定类型参数数量与实现它的具体类不同的泛型接口？

例如：

    public interface IRepository<T1, T2>
    {
        ...
    }
    public class Repository<T1, T2, T3> : IRepository<T1, T2>
    {
        ...
    }

【问题讨论】：

当解析器仅提供 T1 和 T2 时，Ninject 应该如何猜测 T3 参数。您将如何手动执行此操作？
Bind(typeof(IRepository)).To(typeof(Repository));
尝试这样做：To (typeof (Repository <,, C3>))。不幸的是，这也不会编译。

标签： ninject conventions arity

【解决方案1】：

您无法直接执行此操作，但解决方案相当简单：创建一个具有两个继承自 Repository<T1, T2, T3> 的类型参数的新类型，如下所示：

class Rep<T1, T2> : Repository<T1, T2, ActualType>
{
}

这种类型可以直接映射到IRepository<T1, T2>，而不会留下任何未解析的泛型类型参数。

【讨论】：

这有点违背了首先拥有泛型的目的； T3 对于 T1、T2 的每个不同组合都是不同的。
如果 T3 不同，Ninject 无法为您猜出该类型。您必须为每个需要解析的 T1-T2 组合调用 Bind.To。
我就是这么想的。我想也许我可以做一个自定义绑定（IBindingGenerator）并在那里处理它......
只是出于兴趣，在您的情况下选择更正ActualType 的逻辑是什么？
基本上我有一个与我的数据层不同的缓存层。所以我会有类似 IRepository 的东西，它会使用 Repository。这样，我就可以拥有一个使用 EF 获取数据的实现，以及一个使用 XML 文件的实现。每个都将使用相同的业务逻辑接口，但具有不同的实现。因此，在每种情况下，只有一个类实现了 IRepository，但通用签名将不匹配。