Question

我们说我的服务界面如下所示：

public interface IFooService
{
    FooResponse Foo(FooRequest request);
}

在调用类似服务的方法时，我想解决一些跨领域的问题;例如，我想要统一的请求记录，性能记录和错误处理。我的方法是建立一个共同的基础＆＃34; Repository＆＃39;使用Invoke方法的类，它负责调用方法并围绕它执行其他操作。我的基类看起来像这样：

public class RepositoryBase<TService>
{
    private Func<TService> serviceFactory;

    public RepositoryBase(Func<TService> serviceFactory)
    {
        this.serviceFactory = serviceFactory;
    }

    public TResponse Invoke<TRequest, TResponse>(
        Func<TService, Func<TRequest, TResponse>> methodExpr,
        TRequest request)
    {
        // Do cross-cutting code

        var service = this.serviceFactory();
        var method = methodExpr(service);
        return method(request);
    }
}

这很好用。然而，由于类型推断没有按预期工作这一事实阻碍了我使代码更清晰的整个目标。例如，如果我写一个这样的方法：

public class FooRepository : BaseRepository<IFooService>
{
    // ...

    public BarResponse CallFoo(...)
    {
        FooRequest request = ...;
        var response = this.Invoke(svc => svc.Foo, request);
        return response;
    }
}

我收到此编译错误：

方法的类型参数...无法从用法中推断出来。尝试明确指定类型参数。

显然，我可以通过改变我的电话来解决这个问题：

var response = this.Invoke<FooRequest, FooResponse>(svc => svc.Foo, request);

但我想避免这种情况。有没有办法重做代码，以便我可以利用类型推断？

修改

我还应该提一下，早期的方法是使用扩展方法;这种工作的类型推断：

public static class ServiceExtensions
{
    public static TResponse Invoke<TRequest, TResponse>(
        this IService service, 
        Func<TRequest, TResponse> method, 
        TRequest request)
    {
        // Do other stuff
        return method(request);
    }
}

public class Foo
{
    public void SomeMethod()
    {
        IService svc = ...;
        FooRequest request = ...;
        svc.Invoke(svc.Foo, request);
    }
}

Answer 1

问题的标题是“为什么不在此代码中使用类型推断？”我们只是有问题的代码。情景的核心是：

class Bar { }

interface I
{
    int Foo(Bar bar);
}

class C
{
    public static R M<A, R>(A a, Func<I, Func<A, R>> f) 
    { 
        return default(R); 
    }
}

通话网站

C.M(new Bar(), s => s.Foo);

我们必须确定两个事实：A和R是什么？我们还需要了解哪些信息？ new Bar()对应A而s=>s.Foo对应Func<I, Func<A, R>>。

显然，我们可以从第一个事实中确定A必须是Bar。显然，我们可以确定s必须是I。我们现在知道(I s)=>s.Foo对应Func<I, Func<Bar, R>>。

现在的问题是：我们可以通过对lambda正文中的R进行重载解析来推断int是s.Foo吗？

可悲的是，答案是否定的。你和我可以做那个推理，但编译器没有。当我们设计类型推理算法时，我们考虑添加这种“多级”lambda /委托/方法组推理，但认为它的成本太高，无法给它带来好处。

抱歉，你在这里运气不好;一般而言，在C＃方法类型推断中不会进行需要“挖掘”多个功能抽象级别的推论。

为什么使用扩展方法时这会起作用呢？

因为扩展方法没有多个级别的功能抽象。扩展方法案例是：

class C
{
    public static R M<A, R>(I i, A a, Func<A, R> f) { ... }
}

使用呼叫网站

I i = whatever;
C.M(i, new Bar(), i.Foo);

现在我们有什么信息？我们像以前一样推断A是Bar。现在，我们必须推断R知道i.Foo映射到Func<Bar, R>的内容。这是一个简单的过载解决问题;我们假装有一个i.Foo(Bar)的调用，让重载解析完成它的工作。重载分辨率回来并表示i.Foo(Bar)返回int，因此R为int。

请注意，这种推理 - 涉及方法组 - 旨在添加到C＃3，但我搞砸了，我们没有及时完成。我们最终在C＃4中添加了这种推论。

另请注意，要成功进行此类推理，必须已推断所有参数类型。我们必须推断仅返回类型，因为为了知道返回类型，我们必须能够进行重载解析，并且要进行重载解析，我们必须知道所有参数类型。我们不做任何废话，比如“哦，方法组中只有一个方法，所以让我们跳过重载决策，让这个方法自动获胜”。

Answer 2

在您上次修改后，我们发现svc.Foo是一个方法组;这解释了类型推断失败。编译器需要知道类型参数，以便为方法组转换选择正确的Foo重载。

Answer 3

为什么不直接调用该方法？ IE：

public class ClassBase<TService>
{
     protected Func<TService> _serviceFactory = null;

     public ClassBase(Func<TService> serviceFactory)
     {
         _serviceFactory = serviceFactory;
     }

     public virtual TResponse Invoke<TResponse>(Func<TService, TResponse> valueFactory)
     {
          // Do Stuff

          TService service = serviceFactory();
          return valueFactory(service);
     }
}

那么理论上你应该能够做到这一点：

public class Sample : ClassBase<SomeService>
{
     public Bar CallFoo()
     {
          FooRequest request = ...
          var response = Invoke(svc => svc.Foo(request));
          return new Bar(response);
     }
}

为什么不在此代码中使用类型推断？

3 个答案: