是否值得为 .Net 中的非 MVC 项目设置 IoC？
我到处寻找有关 Windsor 或 Spring.net 的信息，它总是参考 MVC。尝试为 Web 表单项目或 WCF 实现它有什么意义吗？
Everywhere I look for information on Windsor or Spring.net its always in reference to MVC. Is there any point trying to implement it for web forms projects or wcf?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
恰巧的是，ASP.NET MVC Web 应用程序的本质非常适合 IoC，因为它处理请求的方式。您可以说 Web 应用程序的启动-请求-响应生命周期，以及 ASP.NET MVC 处理这些事情的方式，直接对应于 Krzysztof Koźmic 所说的 三调用模式以及 Mark Seemann 所说的注册解析发布模式。
然而，有一些方法可以遵循这种模式，即使在不直接适用的应用程序中 - 例如在 WinForms 应用程序、Windows 服务等中
。
我写了一篇关于温莎城堡TypedFactoryFacility 这是 Windsor 的一项功能，允许在代码不知情的情况下调用容器，真正的 IoC 风格。
类型化工厂设施使 Windsor 能够动态实现接口，例如
ISomeFactory，将调用委托给容器的Resolve方法，从而允许您的代码仅依赖于>ISomeFactory接口。It just so happens that the nature of an ASP.NET MVC web application lends itself extremely well to IoC because of the way it handles requests. You can say that the startup-request-response lifecycle of a web application, and the way ASP.NET MVC handles those things, correspond directly to what Krzysztof Koźmic calls The Three Calls Pattern and what Mark Seemann calls Register Resolve Release pattern.
There are ways, however, to follow this pattern even in application that do not directly lend themselves to it - e.g. in WinForms apps, Windows services etc.
<shameless_plug>
I wrote a blog post about Castle Windsor's TypedFactoryFacility that is a feature of Windsor that allows the container to be called, truly IoC style, without your code knowing it.
The typed factory facility makes Windsor capable of dynamically implementing interfaces, like e.g.
ISomeFactory, delegating calls to the container'sResolvemethod underneath, thus allowing your code to depend only on theISomeFactoryinterface.</shameless_plug>
无论它在什么类型的项目中，IoC 都同样有用。它解决的问题（可测试性等...等等...）并不特定于任何特定类型的项目。
IoC is just as useful whatever kind of project it's in. The problems it solves (testability etc... etc...) aren't specific to any particular kind of project.
控制反转（又名依赖注入或第三方连接）只是实现松散耦合的一种方法。
据我所知，只有两种方法可以实现松散耦合：IoC 或服务位置 (这是一种反模式）。 如果您想在任何应用程序中启用松耦合，IoC 就是实现这一目标的方法。
松耦合给您带来了很多好处：
它不依赖于任何特定的架构、模式或应用程序类型。
Inversion of Control (a.k.a. Dependency Injection or Third-party Connect) is just a way to enable loose coupling.
As far as I have been able to identify, there are only two ways to enable loose coupling: IoC or Service Location (which is an anti-pattern). If you want to enable loose coupling in any application, IoC is the way to do it.
Loose coupling gives you a lot of benefits:
It isn't tied to any specific architecture, pattern or type of application.
是的，如果架构要求/允许的话。这取决于整个应用程序的设计，而不仅仅是所使用的 UI 框架。
例如，如果 WebForms 项目将所有内容都放入代码隐藏中并直接从 Page_Load 等访问数据库，那么使用 IoC（或任何类型的重构）将会很困难。
但是，如果 WebForm 正在访问服务或与访问服务或使用存储库等的模型进行交互，那么可以使用某种类型的服务定位器（例如 IoC 框架）注入这些后端对象。连接到 WebForms 类的构造函数可能并不容易（甚至可能，我想我从来没有尝试过），但您仍然可以根据需要解析类内的依赖关系（例如，后期绑定的类属性） ）。
Yes, if the architecture calls/allows for it. It depends on the design of the whole application, not just the UI framework used.
For example, if the WebForms project throws everything into code-behind and is directly accessing the database from Page_Load and such, then using IoC (or any kind of re-factoring) is going to be difficult.
However, if the WebForms are, say, accessing services or are interacting with models which access services or use repositories, etc. then those back-end objects can be injected with a service locator of some kind, such as an IoC framework. Hooking into the constructor of the WebForms classes may not be easy (or even possible, I don't think I've ever tried it), but you can still resolve dependencies within the classes as needed (late-bound class properties, for example).
IoC 与 MVC 完全没有关系。它们是两种完全不同的设计模式。
是否在应用程序中使用 IoC 取决于您的设计。亚格尼？然后就忘了它吧。类之间存在大量依赖关系，导致测试变得困难？立即报名。
IoC 框架并不关心您使用哪种设计模式来实现应用程序。因此，ASPX 文件中的 MVC 或 10k 行代码并不重要。
IoC has absolutely nothing to do with MVC. They are two completely different design patterns.
Whether or not you use IoC in an application depends on your design. YAGNI? Then forget about it. Lots of dependencies between classes that makes testing hard? Sign up immediately.
IoC frameworks don't care what kind of design pattern you use to implement your application. So MVC or 10k lines of code inside your aspx file, it doesn't matter.