依赖注入陷阱
有人在 www 上有一个链接列表来获取 DI 陷阱的好列表吗？ 我一直在尝试在 asp.net webforms 应用程序中使用 DI 注入控件，发现在递归构建时 ViewState 会丢失。 开发人员在应用程序中实施 IoC/DI 之前需要注意的问题的文章列表也会很有帮助。
Does anyone have a list of link(s) on the www for a good list of DI gotchas?
I have been trying to inject controls using DI, in an asp.net webforms app and found that on recursive build up that ViewState is lost.
Also would be helpful a list of articles where the developer needs to be aware to gotchas before taking teh big step in implementing IoC/DI in the app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
DI 本身没有问题。或者更准确地说，这就像枚举一般编程陷阱，例如传递空引用然后不检查它。
正如某些容器所说的那样，“构建”通常是一个坏主意，应尽可能避免。请查看Windsor 常见问题解答，了解一些反对堆积的好理由。这适用于所有 IoC 容器。
特别是，在您的情况下，似乎发生的情况是在控件的 LoadViewState() （或页面的 LoadPageStateFromPersistenceMedium()）之后发生累积，因此它使视图状态无效。也许你的 IoC 容器提供了一个基本控制类，它已经处理了这个问题，而你忘记了继承它。
恕我直言，在 WebForms 中进行 DI 是如此的 hackish（例如本例），以至于我更喜欢诉诸服务位置（仅适用于 WebForms 页面和控件！）。简单，不需要奇怪的技巧。
现在，IoC + DI可能存在一些问题，例如生命周期/范围问题。 Igor Brejc 在本文中对此进行了非常全面的介绍。您必须牢记这一点，特别是在具有大量组件的复杂/大型应用程序中。
DI itself has no gotchas. Or more precisely, it would be like enumerating general programming gotchas, like passing a null reference and then not checking for it.
"Buildup" as some containers put it, is generally a bad idea and should be avoided whenever possible. Take a look at the Windsor FAQ for some good reasons against buildup. This applies to all IoC containers.
In particular, in your case it seems that what's happening is that buildup is happening after the control's LoadViewState() (or the page's LoadPageStateFromPersistenceMedium()) so it renders the viewstate invalid. Maybe your IoC container provides a base control class that already takes care of this and you forgot to inherit it.
IMHO, doing DI in WebForms is so hackish (this very case for example) that I prefer to resort to service location (only for WebForms pages and controls!). Simple, and no weird hacks required.
Now, IoC + DI can have some gotchas, for example lifecycle/scope issues. Igor Brejc covers this very thoroughly in this article. You have to keep this in mind particularly in complex/big applications with lots of components.