您使用新的 Fluent 接口配置 IOC 容器时使用哪些约定/惯用语/模式

Question

我正在将大量代码移至 Castle Trunk，其中包括用于配置容器的新流畅界面。 由于该项目有一个巨大的 WindsorConfig xml 文件，无法维护，因此我想我应该开始利用这个新功能。 我知道其他容器（例如 StructureMap 2.0）也包含用于容器配置的流畅接口，因此这个问题不是基于 Windsor。

我的问题是，您使用新的流畅样式界面进行容器配置时使用什么约定/惯用语/模式？

我的第一个想法是在某处创建一个静态方法（例如 ContainerConfig.Config），它将应用程序使用的所有相关类型加载到容器中。 我担心的是，这个单一的函数最终会像 xml 配置文件一样难以维护（减去尖括号税）。

我的第二个想法是将其分解，以便每个依赖程序集按照惯例导出其默认配置。 我可以看到这对于程序集内部使用的层次结构很有用。 但是对于外部使用的类型是否应该在内部定义配置？

我想得越多，似乎提出的问题就越多。 你对此有什么想法？

Answer 1

您可以尝试检查 Ninject 框架。 非常简单、流畅的界面和闪电般的速度;) 没有 XML 配置并且 API 非常简单。 强烈推荐

Ninject

Answer 2

更深入地了解 StructureMap 2.5。 它提供了多种功能来显着减少引导 IOC 容器的工作。 它提供了一种约定优于配置的技术（请参阅下面的博客条目）

请参阅 Jeremy Miller（StructureMap 的作者）的以下最新博客文章

使用 StructureMap 创建您自己的自动注册约定

        // Example from the blog post above
        var container = new Container(registry =>
        {
            registry.Scan(x =>
            {
                x.TheCallingAssembly();
                x.With<DefaultConventionScanner>();
            });
        });

StructureMap 2.5.2 已发布

Answer 3

我有一个使用 Unity 的项目，我观看了有关 StructureMap 的视频，我从一开始就喜欢注册的想法。

所以我创建了以下接口：

/// <summary>
/// An interface which must be implemented to create a configurator class for the UnityContainer.
/// </summary>
public interface IUnityContainerConfigurator
{
    /// <summary>
    /// This method will be called to actually configure the container.
    /// </summary>
    /// <param name="destination">The container to configure.</param>
    void Configure(IUnityContainer destination);
}

并让程序集提供默认的配置器类。 以便我们可以调用 IoC.Resolve，并且我刚刚向该包装器添加了以下函数：

    /// <summary>
    /// Configure the IoC
    /// </summary>
    public static class Configure
    {
        /// <summary>
        /// Configure the IoC using by calling the supplied configurator.
        /// </summary>
        /// <typeparam name="TConfigurator">The configurator to use</typeparam>
        public static void From<TConfigurator>() where TConfigurator : IUnityContainerConfigurator, new()
        {
            From(new TConfigurator());
        }
        /// <summary>
        /// Configure the IoC using by calling the supplied configurator.
        /// </summary>
        /// <param name="configurationInterface">The configurator instance to use</param>
        public static void From(IUnityContainerConfigurator configurationInterface)
        {
            configurationInterface.Configure(instance);
        }
        // other configuration.
    }

我们还使用静态类包装了 Unity IoC ， 或者我刚刚调用的网站：

IoC.Configure.From<BLL.DefaultMapping>();

在 BLL 中有一个这样的类：

public class DefaultMapping:IUnityContainerConfigurator
{
    public void Configure(IUnityContainer destination)
    {
        destionation.RegisterType<IRepository, SQLRepository>();
        // and more..
    }
}

唯一的缺点是所有层都耦合到所选的 IoC 容器。

更新：自从这个答案之后，我在我的博客上发布了一篇文章，其中包含Unity 包装器。

Answer 4

棘手的问题[而且我不是 IoC 专家]，但请记住，任何“整体静态函数”都不应该像配置文件一样可怕。 您可以定义自己的事物约定，并尝试将事物抽象化。 我使用 Ninject，但对于 Windsor，我想它会涉及使用诸如 Register with the AllTypesOf 策略之类的东西来制作简短的小函数：

kernel.Register(AllTypesOf<ISomethingProvider>.
    FromAssembly(Assembly.Load("SomeAssembly")));

不知道导出自己的默认配置的内部层次结构。 这看起来有点可怕和颠倒。