有没有一种简单的方法可以向温莎城堡注册静态闭包？

我一直在尝试使用命名委托而不是单一方法接口。这对于代码大小有一些优势，我们可以从以下内容开始（删除了一些换行符，以免夸大情况）：

public interface IProductSource
{
    IEnumerable<Product> GetProducts();
}
public class DataContextProductSource : IProductSource
{
    private readonly DataContext _DataContext;
    public DataContextProductSource(DataContext dataContext)
    {
        if (dataContext == null) throw new ArgumentNullException("dataContext");
        _DataContext = dataContext;
    }
    public IEnumerable<Product> GetProducts()
    {
        return _DataContext.Products.AsEnumerable();
    }
}

to:

public delegate IEnumerable<Product> DGetProducts();
public static class DataContextFunctions
{
    public DGetProducts GetProducts(DataContext dataContext)
    {
        if (dataContext == null) throw new ArgumentNullException("dataContext");
        return () => dataContext.Products.AsEnumerable();
    }
}

这基本上是利用了这样一个事实：一旦你在依赖注入方面走得足够远，很多类就变得只不过是闭包。这些类可以替换为返回 lambda 的函数。整个相关函数集（不需要封装任何可变状态，但可以使用“标准”依赖注入中的类来表达），然后可以汇总到静态类（或 VB 术语中的“模块”）中。

这一切都很好，但我无法找到向温莎城堡注册这些静态方法的最佳方法。没有依赖关系的方法很简单：

Component.For<DGetIntegers>().Instance(Integers.GetOneToTen)

但是上面的 DataContextFunctions.GetProducts 有一些依赖性。我发现注册这个的最好方法是：

Component.For<DGetProducts>().UsingFactoryMethod(
    kernel => DataContextFunctions.GetProducts(kernel.Resolve<DataContext>())

这可能会变得非常冗长，并且显然必须直接向内核询问每种依赖项类型有点违背了这一点。在我看来，容器需要的所有静态信息都是可用的，所以应该可以做到这一点。

问题是，温莎城堡（或任何其他容器）是否有一种我错过的简单方法来做到这一点，或者是否出现了技术问题，或者它是否是一个太小众的用例而无法包含在内？

简短回答

您正在尝试使 DI 容器（温莎城堡）执行function构图，但实际上是针对object作品。这只会给你带来很多摩擦。我的猜测是，使用其他容器您也会获得相同的体验。

DI 容器是围绕面向对象的概念设计的 - 特别是 SOLID。它们非常符合这些原则，因为它们的设计是基于对构造函数注入和自动装配等事物的固有理解。

更实用的方法没有什么问题，但我还没有看到围绕函数组合而不是对象组合构建的 DI 容器。

长答案

由于多种原因，使用委托作为 DI 的一般原则在静态类型语言（至少在 .NET 中）中往往会出现问题。从概念上讲，这种方法没有任何问题，因为delegate 可以被认为是一个匿名角色接口 http://blog.ploeh.dk/2009/05/28/DelegatesAreAnonymousInterfaces.aspx。然而，由于类型歧义，它往往变得笨拙。

我通常看到的最常见的方法是使用 BCL 的内置委托，例如Func<T>, Action<T>等等。但是，您可能有许多不同的消费者依赖Func<string>在这种情况下，事情就会变得模棱两可——仅仅因为消费者需要一个Func<string>并不意味着他们需要代表担任相同的角色。虽然机械上可能会与委托一起使用 DI，但会发生什么代表隐藏应用程序角色。角色消失了，只剩下机械师了。

然后，您可以按照 OP 中的建议为每个角色定义自定义委托，如该委托所建议的：

public delegate IEnumerable<Product> DGetProducts();

然而，如果你走那条路，那就一无所获。仍必须为每个角色定义“角色委托”。与定义类似的接口相比，很明显，唯一的节省是几个尖括号和显式方法定义：

public interface IProductSource { IEnumerable<Product> GetProducts(); }

这并不是很多开销（如果有的话）。

您可能还想看看这个讨论：http://thorstenlorenz.wordpress.com/2011/07/23/dependency-injection-is-dead-long-live-verbs/ http://thorstenlorenz.wordpress.com/2011/07/23/dependency-injection-is-dead-long-live-verbs/