由网友(掌心温度。)分享简介：我要创建一个桌面应用程序（使用.NET Windows窗体）从本质上讲，我想创建一个n层应用程序，但我也想层之间的松耦合。但是，我不是很确定这是否是Windows窗体一个好的方法而现在我只是想知道这将是非常明智的选择使用任何的IoC（StructureMap，Ninject，Spring.Net），我以前使用过的Asp...

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

从本质上讲，我想创建一个n层应用程序，但我也想层之间的松耦合。但是，我不是很确定这是否是Windows窗体一个好的方法

而现在我只是想知道这将是非常明智的选择使用任何的IoC（StructureMap，Ninject，Spring.Net），我以前使用过的Asp.Net Web应用程序，但是是什么让我怀疑现在的事实与Windows的工作形成我的业务实体将继续存在，当我浏览的标签，不像比web表单或MVC应用程序哪里会necesary为所执行的每个新的请求注入我的业务实体，我的意思是，因为这个的 Asp.Net页面生命周期的其中执行初始化，并控制实例

这是怎样的一个长远发展的项目，它结合了维修跟踪，库存，工作单和管理报告。我目前正在为它的体系结构的建议。

也许我误解使用IOC的地步，所以请告诉我，你觉得会是一个更好的选择？

的视图的任何位置将AP preciated。

解决方案

它仍然是有意义的使用DI /国际奥委会在你的情况，因为它是所有关于放弃控制那里的依赖从何而来，谁管理他们的生活时，等等。

在这个意义上说，原则控制反转是独立于pretty的多平台，它可能会略有不同的线式术语之间 ASP.NET 和的WinForms ，但主要是相同的。

因此​​而在ASP.NET通常控制的反转通常的实现通过依赖注入的并主要通过构造函数注入到控制器等，这并不意味着你必须遵循同样的模式在Windows窗体 - 例如，你可以只让你的IoC容器适用于所有形式的全局实例，并让他们通过一些得到他们的depdendencies像

  VAR SomeBusinessObject = container.Get＆LT; SomeBOType＆GT;（）; // Ninject风格。
 

在这种情况下，它仍然是国际奥委会（形式并不直接产生依赖，它不知道如果容器给它一个全新的实例，或者说的全局共享的单一静态实例，它不知道什么时候它会被破坏等），但它不是严格意义上依赖的注的 - 但你获得的所有有你受的IoC框架管理复杂的依赖关系图的好处

另外请记住，您可以随时处理，用户切换标签的事件，并将其视为好像它是一个全新的请求，扔掉并重新让你的依赖关系，然后，如果由于某种原因，是重要的是，应用程序应该如何工作。

I am about to create a Desktop App (with .NET windows forms)

Essentially, I want to create an n-tier app but I also want loose coupling between layers. However, I am not very sure if this is a good approach for windows forms

And now I just wonder if it would be really a wise choice to use any IoC (StructureMap, Ninject, Spring.Net), I have used them before for Asp.Net web applications but what makes me doubt now is the fact that working with windows forms my business entities will persist when I navigate through tabs and unlike than web forms or mvc apps where it would be necesary to inject my business entity for every new request that is performed, I mean this because of the Asp.Net page life cycle where is performed the initialization and controls instantiation.

This it is kind of a long-term development project, it combines maintenance tracking, inventory, work orders, and management reporting. I am currently working on a proposal for its architecture.

Maybe I am misunderstanding the point of using an IoC, so please tell me what do you think would be a better choice?

Any point of view would be appreciated.

解决方案

It still makes sense to use DI / IoC in your case, because it's all about surrendering control of where the dependencies come from, who manages their life-time, etc.

In that sense, the principle Inversion of Control is pretty much platform independent, it may work slightly differently in terms of wire-up between ASP.NET and WinForms, but the principal is the same.

So whereas in ASP.NET typically the Inversion of Control is typically realised via Dependency Injection and mostly via Constructor Injection into Controllers, etc, that doesn't mean you have to follow the same pattern in Windows Forms - for example, you could just make a global instance of your IoC Container available to all Forms, and have them get their depdendencies via something like

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

In this case it's still IoC (the form doesn't directly create the dependency, it has no idea if the container is giving it a brand new instance, or a single static instance that's globally shared, it doesn't know when it will be destroyed, etc) but it's not strictly speaking Dependency Injection - however you gain all of the benefits of having complex dependency graphs managed for you by the IoC framework.

Also bear in mind that you can always handle the event where the user switches tabs, and treat that as though it were a brand new "request", throwing away and re-getting your dependencies then, if for some reason that is important for how the app should work.