c# - JavaScript DI/IoC 等效于静态类型语言的标准 DI 模式

Question

.NET 和 Java 都有大量可用的 DI/IoC 容器，并且每个
有许多我发现在不同方面非常有用的模式
与他们合作。我现在正处于我想做等价的地步
JavaScript 中的东西。由于 JavaScript 是一种动态语言，我不期望
DI/IoC 容器与提供的所有功能直接等效
通过在静态类型语言中找到的容器，因此可以替代这些
欢迎使用图案。我还希望 DI/IoC 容器可用于
JavaScript 的功能会有所不同，因此引用不同的
容器非常受欢迎。

以下模式是 Autofac 3 支持的模式我相信是
适用于动态语言。有关这些模式的一般信息
和关系，见
http://autofac.readthedocs.org/en/latest/resolve/relationships.html和
http://nblumhardt.com/2010/01/the-relationship-zoo/ .大多数(如果不是全部)
以下概念也适用于其他语言和 DI/IoC 容器
如 Google Guice和 Spring .

以下 JavaScript 中描述的概念和模式最接近的等价物是什么？

一般概念

概念 1:向 IoC 容器注册

在 IoC 容器可以创建类型的实例之前，它需要知道
类型的。这是通过注册完成的。注册通常完成
声明性地:

class A {}
var builder = new ContainerBuilder();
builder.RegisterType<A>();

以上使 IoC 容器知道类型 A。它发现 A 的
通过反射依赖。注册也可以通过
充当工厂的函数。这些函数通常是 lambdas 并且可能是
内联写:

class B {}
class A {
    A(string name, B b) { }
}
builder.RegisterType<B>();
builder.Register(c => // c is a reference to the created container
    new A("-name-", c.Resolve<B>()));

能够提供工厂函数在你有一个
需要使用不是服务的依赖项参数化的类型，
比如上面例子中的名字。

由于 C# 支持接口(interface)和抽象类，因此它通常不是
重要的具体数据类型，而不是它的抽象类型
实现。在这些情况下，您会将类型注册为接口(interface)或
它应该可用的抽象类:

interface IPlugin {}
class P : IPlugin
builder.RegisterType<P>().As<IPlugin>();

通过上述注册，任何请求 P 的尝试会失败，但是一个
请求 IPlugin会成功。

概念 2:容器创建和组合根

执行完所有注册后，容器需要
创建:

public class Program {
    public static void Main(string[] args) {
        var builder = new ContainerBuilder();
        /* perform registrations on builder */
        var container = builder.Build();
        /* do something useful with container */
    }
}

容器在程序生命周期的早期创建并成为
组合根 - 组合所有部分的代码中的位置
的应用程序，确保创建所有必要的依赖项。
然后使用容器来解析内部的主要组件
应用:

public static void Main(string[] args) {
    var builder = new ContainerBuilder();
    /* perform registrations on builder */
    var container = builder.Build();
    var application = container.Resolve<Application>();
    application.Launch();
}

概念 3:生命周期和实例管理

鉴于:

class A {}

如果我们想要为每个依赖项创建一个新的 A 实例，它可以是
注册为 builder.RegisterType<A>()无需指定任何内容
更远。

如果我们希望每次需要返回 A 的相同实例
将其注册为“SingleInstance”:

builder.RegisterType<A>().SingleInstance();

有时我们想在某个范围内共享一个实例，但对于
不同的范围我们想要不同的实例。例如，我们可能想要
在用于处理特定数据的所有 DAO 中共享一个数据库连接
HTTP 请求。这通常通过为每个 HTTP 创建一个新范围来完成
请求，然后确保使用新范围来解决
依赖关系。在 Autofac 中，这可以手动控制，如下所示:

builder.RegisterType<A>().InstancePerLifetimeScope();
var scope = container.BeginLifetimeScope();
// within the request's scope
var root = scope.Resolve<RequestProcessor>();
root.Process();

一般模式

模式 1:A 需要 B 的实例

class B {}     // registered as: builder.RegisterType<B>()
class A {      // registered as: builder.RegisterType<A>()
    A(B b) {}
}

var a = container.Resolve<A>();

IoC 容器使用反射发现对 B 的依赖并注入(inject)
它。

模式 2:A 在 future 的某个时间点需要 B

class B {}
class A {
    A(Lazy<B> lazyB) {
        // when ready for an instance of B:
        try {
            var b = lazyB.Value;
        } catch (DependencyResolutionException) {
            // log: unable to create an instance of B
        }
    }
}

在这种模式中，依赖项的实例化需要延迟
一些理由。在这种情况下，让我们假设 B 是由第三个创建的插件
党，其 build 可能会失败。为了安全地使用它，
对象构造必须受到保护。

模式 3:A 需要创建 B 的实例

class B {}
class A {
    A(Func<B> factory) {
        try {
            // frequently called multiple times
            var b = factory.Invoke();
        } catch (DependencyResolutionException) {
            // log: Unable to create
        }
    }
}

这种模式通常用于需要创建多个
非值对象的实例。这也允许创建
推迟的实例，但通常出于与那些不同的原因
在模式 2 中(A 在将来的某个时候需要 B)。

模式 4:A 向 B 提供 X 和 Y 类型的参数。

class X {}
class Y {}
class B {
    B(X x, Y y) { }
}

当需要注入(inject)的依赖项时通常使用此模式
控制或配置。例如，考虑一个需要数据库的 DAO
提供的连接字符串:

class DAO {
    DAO(string connectionString) {}
}
class A {
    A(Func<DAO> daoFactory) {
        var dao = daoFactory.Invoke("DATA SOURCE=...");
        var datum = dao.Get<Data>();
    }
}

模式 5:A 需要所有类型的 B

interface IPlugin {}
class X: IPlugin {} // builder.RegisterType<X>().As<IPlugin>()
class Y: IPlugin {} // builder.RegisterType<Y>().As<IPlugin>()
class Z: IPlugin {} // builder.RegisterType<Z>().As<IPlugin>()
class A {
    A(IEnumerable<IPlugin> plugins) {
        foreach (var plugin in plugins) {
            // Add all plugins to menu
        }
    }
}

在此模式中，对给定类型进行了多次注册。消费者
然后可以请求该类型的所有实例并相应地使用它们。

模式 6:A 需要知道 B，或 A 需要知道 X 关于 B

class B {} // builder.RegisterType<B>().WithMetadata("IsActive", true);

// A needs to know about B
class A {
    A(Meta<B> metaB) {
        if ((bool)metaB.Metadata["IsActive"]) {
            // do something intelligent...
        }
    }
}

// OR...

class B {} // builder.RegisterType<C>().WithMetadata<X>(...);
class X {
    bool IsActive { get; }
}

// A needs to know X about B
class A {
    A(Meta<B, X> metaB) {
        if (metaB.IsActive) {
            // do something intelligent...
        }
    }
}

让我们再次假设我们有一个使用插件的系统。插件可能是
根据用户的意愿启用或禁用或重新排序。通过关联元数据
对于每个插件，系统可以忽略不事件的插件，或者将插件放入
用户想要的顺序。

模式 7:上述模式的组合

interface IPlugin:
class Plugin1 : IPlugin {}
class Plugin2 : IPlugin {}
class Plugin3 : IPlugin {}
class PluginUser {
    PluginUser(IEnumerable<Lazy<IPlugin>> lazyPlugins) {
        var plugins = lazyPlugins
                        .Where(CreatePlugin)
                        .Where(x => x != null);
        // do something with the plugins
    }

    IPlugin CreatePlugin(Lazy<IPlugin> lazyPlugin) {
        try {
            return lazyPlugin.Value;
        } catch (Exception ex) {
            // log: failed to create plugin
            return null;
        }
    } 
}

在此代码示例中，我们请求包含在 Lazy 对象中的所有插件的列表
以便在将来的某个时候创建​​或解决它们。这个
允许保护或过滤它们的实例化。

模式 8:适配器

这个例子取自:
https://code.google.com/p/autofac/wiki/AdaptersAndDecorators

interface ICommand {}
class SaveCommand: ICommand {}
class OpenCommand: ICommand {}
var builder = new ContainerBuilder();

// Register the services to be adapted
builder.RegisterType<SaveCommand>()
       .As<ICommand>()
       .WithMetadata("Name", "Save File");
builder.RegisterType<OpenCommand>()
       .As<ICommand>()
       .WithMetadata("Name", "Open File");

// Then register the adapter. In this case, the ICommand
// registrations are using some metadata, so we're
// adapting Meta<ICommand> instead of plain ICommand.
builder.RegisterAdapter<Meta<ICommand>, ToolbarButton>(
   cmd =>
    new ToolbarButton(cmd.Value, (string)cmd.Metadata["Name"]));

var container = builder.Build();

// The resolved set of buttons will have two buttons
// in it - one button adapted for each of the registered
// ICommand instances.
var buttons = container.Resolve<IEnumerable<ToolbarButton>>();

以上允许所有注册的命令自动适应 ToolbarButton使它们易于添加到 GUI。

模式 9:装饰器

interface ICommand {
    string Name { get; }
    bool Execute();
}
class SaveCommand : ICommand {}
class OpenCommand : ICommand {}
class LoggingCommandDecorator: ICommand {
    private readonly ICommand _cmd;
    LoggingCommandDecorator(ICommand cmd) { _cmd = cmd; }
    bool Execute() {
        System.Console.WriteLine("Executing {0}", _cmd.Name);
        var result = _cmd.Execute();
        System.Console.WriteLine(
            "Cmd {0} returned with {1}", _cmd.Name, result);
        return result;
    }
}

// and the corresponding registrations
builder.RegisterType<SaveCommand>().Named<ICommand>("command");
builder.RegisterType<OpenCommand>().Named<ICommand>("command");
builder.RegisterDecorator<ICommand>((c,inner) =>
    new LoggingCommandDecorator(inner), fromKey: "command");
// all ICommand's returned will now be decorated with the
// LoggingCommandDecorator. We could, almost equivalently, use
// AOP to accomplish the same thing.

概括

首先，尽管我试图让这些示例合理地代表所描述的模式，但这些示例是说明性的玩具示例，由于空间限制可能并不理想。对我来说更重要的是
概念、模式和最接近的 JavaScript 等价物。如果大多数 IoC/DI 容器在
JavaScript 不支持上面的一些模式，因为有很多
更简单的方法来做到这一点，足够公平。

以下 JavaScript 中描述的概念和模式最接近的等价物是什么？

Answer 1

您提到的某些功能是通过使用 AMD 实现的。
例如看 RequireJS:http://requirejs.org/docs/whyamd.html

另一个值得关注的实现是 Angular JS DI:
https://docs.angularjs.org/guide/di

您可以轻松注入(inject)模块(封装在闭包和元数据中的功能单元)
以这种方式抽象了实现。它允许切换实现，
在测试单元中运行模拟等等。

希望能帮助到你