编译时/构建后依赖注入IoC？

Question

我目前使用NInject将接口绑定到具体类型,并将它们注入到我的类中.但是,据我了解,这是一个运行时间.对我来说,如果有人想改变我的应用程序的行为,它似乎是一个攻击点.

有什么东西可以让我将依赖注入IoC迁移到编译时间(阅读:构建后的IL编织/替换)？

---

详细说明

在我的代码中,我设置了一个绑定

Bind<IFoo>().To<Foo>()
Bind<Bar>().ToSelf().InSingletonScope();

与ctor Foo(Bar dependency)

在我的应用程序的根源(启动时)我解析图表

var foo = kernel.Get<IFoo>();

假设我没有服务定位器(反模式无论如何吧？).所以我再也没用kernel了.

现在我希望有一个"post-build release-compile",用instanciators替换内核的解析引擎,或者引用constant/singleton等.这样我的代码就像这样;

var foo = kernel.Get<IFoo>();

实际上,在我的最终构建阶段更换IL之后,它看起来像这样:

var bar = new Bar(); 
var foo = new Foo(bar);

并且不再提及NInject了.

我对这个问题的理性是,我正在使用Fody来IL Weave我所有的PropertyChanged提升者,我想知道是否有可能为Dependency Injection做类似的事情.

Answer 1

从安全角度来看,使用DI容器不会对您的应用程序造成任何额外的威胁.

当您编写服务(例如Web服务或Web站点)应用程序时,攻击者只能在该应用程序或服务器已被泄露时更改应用程序的DI配置行为.发生这种情况时,应将服务器视为丢失(您必须重新格式化该服务器或将其完全丢弃).DI不会使情况变得更糟,因为DI容器通常不允许从外部改变行为.为了实现这一点,你将不得不做一些非常奇怪的事情.

另一方面,对于在用户计算机上运行的应用程序,您应该始终认为该应用程序会受到攻击,因为攻击者可以反编译您的代码,在运行时更改行为等.再次,DI不会使这更糟糕,因为你只能保护自己免受对服务边界的攻击.该客户端应用程序必须与服务器通信,并且存储贵重资产的位置在服务边界内.例如,您不应该在客户端的DLL中存储帐户密码.无论是否加密.

但是,使用DI可以使攻击者更容易更改客户端应用程序的行为,尤其是在使用XML配置所有内容时.但这适用于您在配置文件中存储的所有内容.如果这是你唯一的防线(无论是否带有DI)你都会被搞砸.

如果有人想改变我的应用程序的行为,它似乎是一个攻击点

请注意,任何应用程序都可以反编译,更改和重新编译.无论是管理(.NET,Java)还是不管理(C++),或者是否进行模糊处理都无关紧要.因此,从安全角度来看,无论是运行时DI还是编译时DI都无关紧要.如果这是一个问题,请不要在无法控制的计算机上部署该代码.

Answer 2

正如所讨论的，您所引用的这样做的原因并不成立。然而，Philip Laureano（Linfu 作者）不久前做了一个Hiro 项目，它做了预部署 DI。不知道它是否去了任何地方......