编译时IOC


11

是否有人在编译时启动了一个要进行IOC的项目(可能使用Roslyn或Linq MethodInfo发出)?

到目前为止,我在IOC容器方面的经验非常好,排除了一些小问题

  1. 许多IOC容器启动缓慢,因为许多解析逻辑都在这里发生
  2. 通常很难确保可以解决,因为编译不再确保可以调用构造函数。
  3. 通常,IOC容器会增加运行时的开销(有些甚至不小,通常那些启动很快的容器运行缓慢)

在我看来,理想的解决方案是在构建链上添加一个编译步骤,该步骤添加一个Factory类而不是IOC。

有人做过吗?如果没有,为什么不呢?

Answers:


4

这样做应该不是问题。只需运行相同的IoC逻辑,而不是实例化类,而是发出执行实例化的代码。

但是通过这样做,您将消除IoC的一个巨大优势:无需重新编译整个应用程序即可更改组成部分的方式的能力。仅通过替换配置,您就可以使应用程序使用不同的服务或数据源。虽然我还没有看到可以充分利用此功能的应用程序,但它仍然是IoC成功的主要部分。


是的,我知道这是可能的。但是我还没有看到可以做到的IoC容器。我还注意到,当前的趋势似乎是朝着在代码(流利的API)中注册。鉴于此,我正在考虑编写所说的IoC容器。
ArTs 2014年

我似乎记得Hiro(github.com/philiplaureano/Hiro)可能在编译时就做了。
lzcd

2
“但是这样做,您将消除IoC的一个巨大优势:无需重新编译整个应用程序即可更改组成部分的方式的能力。” 在我看来,将其应用于整个应用程序是过大的。您正在将应用程序的每个部分变成一个插件。此外,这两种技术应该能够共存-没有理由您不能在编译时连接某些组件,而在运行时连接某些组件。
Doval

我看不出这是多么巨大的优势。您在什么情况下会在运行时完全替换组件?可能有一些配置用例?
andyczerwonka

4

Java / Android的Dagger可以做到这一点。它牺牲了一些运行时魔术(例如Guice's)来提供几乎完全的编译时代码生成体验,包括将大多数运行时错误转换为编译错误。

.NET也很酷。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.