使用 ninject (DI) 通过 Webforms 和 MVP 实例化演示者
我有一个网络表单应用程序，我想在其上使用依赖注入。我意识到我不能使用 DI 来构造每个页面，因为 webforms 没有像 aspnet MVC 那样的适当的钩子。
Nate Kohari 在ninject 邮件列表上建议您可以创建一个基本页面它将通过属性注入来处理依赖关系解析，这看起来确实可行。
但是我的 webforms 应用程序实现了模型-视图-演示者模式，我想知道为什么我不能只使用容器来解析视图构造函数中的演示者，因为我的演示者应该具有我需要解决的所有依赖项？是否有任何我想要/需要解决的直接位于视图上的依赖项？
I've got a webforms app that I'd like to use dependency injection on. I realize that I can't use DI to construct the each Page because webforms doesn't have the proper hooks like aspnet MVC does.
Nate Kohari suggests on the ninject mailing list that you could create a base page that would handle dependency resolution via property injection, which certainly seems like it would work.
But my webforms app implements the Model-View-Presenter pattern and I want to know why I couldn't just use my container to resolve my Presenter in the view's constructor since my presenter should have all the dependencies that I would need to resolve? Is there any dependency that I would want/need to resolve that sits directly on the view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
查看该链接，我发现他/她的建议与您在上一段中提到的替代方案之间没有功能差异。将内核属性放在基页中似乎是过度设计的，因为无论如何您都将在某个时刻访问静态内核。
Looking at the link, I see no functional difference between what he/she is suggesting and the alternative you mention in your last paragraph. Having the kernel property in the base page seems overengineered, since you are just going to be accessing a static kernel at some point anyway.