.NET Framework中的控制和依赖注入反转

Sha*_*10N 13 .net c# dependency-injection inversion-of-control

是否有任何特定的DI示例/实例作为.NET Framework本身的架构原则或设计模式应用?框架/ BCL中的任何(或许多)类型是否符合IoC?

基于C#的类型名称和简要说明/解释会很棒!

这将使得DI注入设计原则的需求成为最佳实践......因为它是从基础框架本身收集的.

我重申,我不是在寻找的IoC/DI框架BUT为IOC/DI IN的框架.

编辑:只是想得到更多的实例/例子......因此赏金!

Mar*_*ann 16

一般来说,BCL中没有很多DI的例子 - 也许是因为BCL是一个相当独立的框架,DI更多的是应用程序架构的关注......但是,这里有一些例子我一直在能找到目前为止.

构造函数注入

BCL中没有很多构造函数注入的例子.最好的候选人是

  • System.IO.StreamWriter
  • 就是System.IO.StreamReader

物业注入

  • System.ComponentModel.IComponent.Site

我们还看到了Workflow Foundation WorkflowRuntime.AddService和相关方法的变体,尽管您可能会认为这更接近于Method Injection.

方法注入

  • System.ComponentModel.Design.IDesigner.Initialize
  • System.ComponentModel.TypeConverter(许多方法采用ITypeDescriptorContext)
  • System.Web.Mvc.IModelBinder.BindModel(来自ASP.NET MVC)

环境背景

  • System.Threading.Thread.CurrentPrincipal
  • System.Threading.Thread.CurrentCulture
  • System.Threading.Thread.CurrentUICulture
  • System.Diagnostics.Trace.Listeners

FWIW,我从即将出版的书中提取了这些例子.

  • 我想我真的无法与那些写过这本书的书的人竞争......我很高兴我从列表中找到了一个例子.哈哈. (4认同)

Jus*_*ner 12

StreamReader和StreamWriter都可以看作是IoC/DI的例子.

每个允许您分别注入不同的Stream对象(或其衍生物之一)进行读/写.

FileInfo fi = new FileInfo(@"C:\MyFile.dat");
StreamWriter sw = new StreamWriter(fi.Open());
Run Code Online (Sandbox Code Playgroud)

要么:

MemoryStream ms = new MemoryStream();
StreamWriter sw = new StreamWriter(ms);
Run Code Online (Sandbox Code Playgroud)

两者都允许:

sw.Write("Hello world!");
Run Code Online (Sandbox Code Playgroud)

同样的方式,无论你在构造函数的调用中注入了什么样的Stream.


Aar*_*ght 5

当然 - 自1.0以来,IServiceProvider接口已成为Framework的一部分.这不是DI,因为它通常在这里讨论(使用"内核"),但它是IoC使用服务定位器模式.

如果你深入研究任何Windows窗体设计器代码,你会看到它充满了像这样的行:

IDesignerOptionService service = 
    (IDesignerOptionService)this.GetService(typeof(IDesignerOptionService));
Run Code Online (Sandbox Code Playgroud)

如果您正在使用Component,那么您可以通过Site属性访问它.在创建自定义控件时,这是非常常见且实际需要的知识.

这是服务位置,教科书示例.你有一个通用的IServiceProvider,它可以提供你按服务类型请求的抽象服务.如果您想创建自定义设计器 - 智能标签等 - 那么您需要了解所有这些.它与ASP.NET类似.


PS请不要在新代码中使用 IServiceProvider.这是一个非常古老的非通用接口.如果要创建需要IoC容器才能工作的可重用库,则应使用Common Service Locator.但是,除非您绝对要求您的库与应用程序层使用的DI库无关,否则不要使用 ; 大多数特定于实现的容器/内核提供了更多更丰富的API,如果您将自己钉在CSL上,那么您将错过这些API.