Webforms和依赖注入 [英] Webforms and Dependency Injection

问题描述

我正在将现有WebForms应用程序（使用Castle Windsor）引入依赖注入框架。

I am in the process of introducing a Dependency Injection framework into an existing WebForms application (using Castle Windsor).

我在DI方面有很深入的经验，而且倾向于非常强烈地希望通过setter注入进行构造器注入。如果你熟悉Webforms，你知道ASP.Net框架处理页面和控件对象的构造，使得真正的构造器注入变得不可能。

I have pretty deep experience with DI, and tend to very strongly favor constructor injection over setter injection. If you are familiar with Webforms, you know that the ASP.Net framework handles the construction of page and control objects, making true constructor injection impossible.

我目前的解决方案是在Global.asax的Application_Start事件中注册该容器，并将该容器作为公共静态变量保存在Global中。然后，我简单地解决我需要时直接在页面或控件中的每个服务。所以在每个页面的顶部，我最终得到这样的代码：

My current solution is to register the container in the Application_Start event of the Global.asax, and keep the container as a public static variable in Global as well. I then simply resolve each service that I need directly in the page or control when I need them. So at the top of each page, I end up with code like this:

private readonly IMyService _exposureManager = Global.IoC.Resolve<IMyService>();
private readonly IMyOtherService _tenCustomersExposureManager = Global.IoC.Resolve<IMyOtherService>();

显然，我不喜欢让所有这些对容器的引用分散在我的应用程序或让我的页面/控件依赖关系是非显式的，但是我还没有找到更好的方法。

Obviously, I don't like having all these references to the container scattered about my application or having my page/control dependencies be non-explicit, but I have not been able to find a better way.

有没有更好的解决方案来使用DI与Webforms？ p>

Is there a more elegant solution for using DI with Webforms?

推荐答案

我同意@DarinDimitrov MVP是一个有趣的选择。然而，当使用遗留应用程序时，将现有页面重写为MVP模式是一项工作。在这种情况下，您可能会更好地从UI中开始使用服务定位器模式（但仅限于 ）。但是，请改变一件事情。不要将所选的DI容器暴露在应用程序中，正如我预期的那样，您正在使用 Global.IoC 属性。

I agree with @DarinDimitrov that MVP is an interesting option. However, when working with a legacy application, rewriting an existing page to the MVP pattern is a hell of a job. In that case it might be better to start with the Service Locator pattern (but only in your UI classes) as you are already doing. However, do change one thing. Do not expose the chosen DI container to the application, as I expect you are doing with the Global.IoC property.

而是在 Global 类上创建一个静态 Resolve< T> 方法。这完全隐藏容器，允许您交换实现，而无需更改网页中的任何内容。当您这样做时，在@Wiktor建议的使用通用服务定位器方面没有任何优势。公共服务定位器只是不必抽象的东西的另一个抽象（因为您已经使用 Global.Resolve< T> 抽象出容器） 。

Instead, create a static Resolve<T> method on the Global class. This hides the container completely and allows you to swap implementations without having to change anything in your web pages. When you do this, there is no advantage in using the Common Service Locator as @Wiktor proposes. The Common Service Locator is just another abstraction for something that doesn't have to be abstracted (since you've already abstracted away the container using the Global.Resolve<T>).

不幸的是，Web表单，没有什么好的方法来做到这一点。对于简单注射器，我写了一个 Web表单集成指南，基本上描述了使用 Global.Resolve< T> 方法，但也显示了一种测试是否可以创建Page类的方法。该指南也可以用于其他DI容器。

Unfortunately with Web forms, there is not really any good way to do this. For Simple Injector, I wrote an integration guide for Web Forms that basically describes the use of the Global.Resolve<T> method, but also shows a way to tests if Page classes can be created. The guide can be used for other DI containers as well.

BTW，请记住，随着城堡温莎，您要求的所有内容必须明确发布（注册解析版本模式）。这是一个令人讨厌的（IMO），不同于其他容器如何工作，可能是内存泄漏的来源，当你不这样做。

BTW, please keep in mind that with Castle Windsor, everything you request must be released explicitly (the Register Resolve Release pattern). This is a bit nasty (IMO) and differs from how other containers work and can be a source of memory leaks when you do not do this correctly.

最后一个注释。 可以使用Web窗体进行构造函数注入。好吧，因为这将使用默认构造函数创建 Form 之后，使用反射调用重载的构造函数，所以这会导致时间耦合。

Last note. It is possible to do constructor injection with Web Forms. Well... sort of, since this will call the overloaded constructor using reflection after the Form has been created using the default constructor, so this causes Temporal Coupling.

这篇关于Webforms和依赖注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！