DI 在桌面应用程序中有意义吗？

我即将创建一个桌面应用程序（使用 .NET Windows 窗体）

本质上，我想创建一个 n 层应用程序，但我也希望各层之间松散耦合。但是，我不太确定这对于 Windows 窗体来说是否是一个好方法

现在我只是想知道使用任何 IoC（StructureMap、Ninject、Spring.Net）是否真的是一个明智的选择，我之前曾在 Asp.Net Web 应用程序中使用过它们，但现在让我怀疑的是，与当我浏览选项卡时，Windows 表单我的业务实体将持续存在，与 Web 表单或 MVC 应用程序不同，在 Web 表单或 MVC 应用程序中，需要为执行的每个新请求注入我的业务实体，我的意思是因为Asp.Net页面生命周期 http://msdn.microsoft.com/en-us/library/ms178472.ASPX在哪里执行初始化并控制实例化。

这是一个长期开发项目，它结合了维护跟踪、库存、工作订单和管理报告。我目前正在制定其架构提案。

也许我误解了使用 IoC 的意义，所以请告诉我你认为更好的选择是什么？

任何观点将不胜感激。

在您的情况下使用 DI / IoC 仍然有意义，因为这一切都是为了放弃对依赖项来自何处、由谁管理其生命周期等的控制。

从这个意义上讲，原则Inversion of Control几乎是独立于平台的，它在连接方面可能略有不同ASP.NET and WinForms，但原理是一样的。

因此，在 ASP.NET 中，控制反转通常是realised via Dependency Injection并且主要通过构造函数注入到控制器等中，这并不意味着您必须在 Windows 窗体中遵循相同的模式 - 例如，您可以使 IoC 容器的全局实例可供所有窗体使用，并让它们获得它们的通过类似的东西的依赖关系

var SomeBusinessObject = container.Get<SomeBOType>(); //Ninject style.

在这种情况下，它仍然是 IoC（表单不会直接创建依赖项，它不知道容器是否为它提供了一个全新的实例，或者全局共享的单个静态实例，它不知道什么时候会被破坏等），但严格来说这不是依赖关系注射- 但是，您可以获得 IoC 框架为您管理的复杂依赖关系图的所有好处。

另请记住，您始终可以处理用户切换选项卡的事件，并将其视为一个全新的“请求”，然后丢弃并重新获取您的依赖项，如果由于某种原因这对于如何进行操作很重要该应用程序应该可以工作。