IoC 和 ASP.NET MVC，这一切从哪里开始？

Question

我看到 ASP.NET MVC 中几乎到处都提到了“IoC”和“DI”。虽然我很清楚……“有点”这些是什么，但它是那些几乎模糊的、无定形的浮动概念之一，它似乎要么已经被我忽略，要么我只是没有找对地方。随着 ASP.NET MVC 3.0 即将发布，我对它的认识更加深刻。如此之多以至于感觉它是我不知道的编程的整个部分。

我尝试过寻找有关该主题的书籍，但我发现的大多数内容似乎都做出了很多假设（Ruby 的历史、理解它是什么但不知道如何使用它等）。

我只是预先简单地询问。 IoC 是什么？我为什么关心它？有没有一些不错的网站可以从初学者程序员的角度介绍这一点？假设我对此一无所知。假设我除了 C# 之外一无所知。我阅读了从 .NET 1.1 到 .NET 2.0 的所有关于 C# 的书籍、博客和教程，当 .NET 3.5 和 LINQ 出现时，它变得如此难以处理，以至于我无法跟上。我是一名使用 ASP.NET MVC/C# 的菜鸟开发人员，我不禁觉得我错过了一些非常重要的东西。 （我对 DI（依赖注入）有很多相同的感受）

我用谷歌搜索过，我读过博客，我看过 Castle.Windsor，我看过示例代码，我浏览过书籍和网络广播，但我还是那么一无所知。这感觉就像是你知道你应该知道的工作内幕故事之一，但出于某种原因，你不知道，而且学校也没有真正让我为此做好准备。

对我来说，StackOverflow 一直是开发社区中最好的。通过大学和入门工作以及低水平的自由职业，我融合了其他程序员的编程教育（尽管据我了解，这不一定是值得羞耻的事情）。因此，我再次向社区声明。

啊？我不明白。

与许多试图进入同一领域的同事交谈时，他们中的许多人都有同样的感觉。所以我不禁感觉到，我们这些“新手”程序员错过了这些概念性编码方法的备忘录。我不仅想得到这个问题的答案，而且我认为对于像我这样试图理解它的其他人来说，一个好的线索可能是一个聪明的想法（如果存在，它需要变得更加明显

）我发现有帮助的是http://www.theserverside。 com/news/1321158/A-beginners-guide-to-Dependency-Injection 和 http://www.dotnetspark.com/kb/1222-inversion-control--beginner-guide.aspx

但我仍然对许多问题摸不着头脑，为什么这很重要。说实话，我觉得开发者社区的很大一部分实际上对 IoC 和单元测试都有这种感觉。很少有人阐述它是什么，而且发现的例子通常都很差，或者很难理解。当 .NET 推出时，它是独立的。我不需要一堆其他概念来运行简单的程序。现在，.NET 是一种受人尊敬的语言，世界上的一切都在采用它（nHibernate、MVC、MVP、MVVP、云平台、游戏架构等）

（如果我是公然错误，请随时指出。我是无论如何，我不会称自己为“好”，但我很了解 C#，我认为自己学得很快，尽管我在这方面遇到了困难，但我只能假设有一些“能力”。那里有需要填补的洞）

Answer 1

让我们把所有 IoC 框架放在一边并讨论这个概念。 IoC 并不是一个新概念，并且已经存在很长时间了。 IoC 的实现基本上是为了使您的系统与某些子系统松散耦合。我们通过将子系统的公共/核心行为提取到合约中来实现解耦。契约通常是界面的形式。现在你依赖这个接口了。您并不担心特定系统如何具体地为您提供您所追求的行为。

最近我在现实生活中遇到了这个。我们现有一个支付系统，然后我们正在开发一个新的支付系统以遵守 PCI。在这种情况下，您要做的就是在界面中提取两个系统的共同特征，然后您的应用程序仅通过界面与这两个系统进行交互。您可以在配置文件或工厂模式中使用标志，或者最终使用 IoC 框架在应用程序中注入此依赖项。在运行时，您的应用程序将获取它所依赖的对象。您需要在由于任何原因而导致任何给定子系统的使用存在不确定性的环境中使用 DI/IoC。在此示例中，新的支付系统无法按时交付，因此我的应用程序需要一个可配置选项来在运行时在任何系统之间切换。如果我不做 IoC，每次业务改变主意时我都必须更改代码。

IoC的另一个需求是做TDD。我上面描述的同样的东西可以用来开发真实应用程序的模拟实现，并且可以用来在真实组件仍在开发中时进行测试。

依赖注入是一本很好的入门书。您还可以在此处下载同一作者关于 DI 的免费论文。

更新：添加代码以更加清晰

public interface ITest
    {
        void Hello();
    }

现在我可以有两种不同的具体实现：

public class Hi : ITest
    {
        public void Hello()
        {
            HttpContext.Current.Response.Write("Hi there!");
        }
    }

    public class HelloMessage : ITest
    {
        public void Hello()
        {
            HttpContext.Current.Response.Write("Hello there!");
        }
    }


ITest messenger;

if (User Needs "Hi")
{
   messenger = new Hi();
}
else if (User Needs "Hello")
{
   messenger = new HelloMessage();
}

messenger.Hello(); 

我的应用程序所要做的就是调用合同中可用的方法。现在应用程序正在显式处理依赖项，但没有任何具体实现。然而它仍然与这两个具体实现相关。 IoC 框架帮助我们将这项工作外包给配置文件。在那里，我可以提供任何其他具体实现，无论它是如何实现的，并且应用程序将继续工作而无需任何代码更改。

以下是我使用 Unity 2 并自行外包显式依赖处理的代码。

using (IUnityContainer container = new UnityContainer())
            {
                container.LoadConfiguration();

                ITest messenger = container.Resolve<ITest>();

                messenger.Hello();
            }

相同的配置：

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
  <assembly name="Injection"/>
  <container>
    <register type="Injection.ITest" mapTo="Injection.Hi"/>
  </container>
</unity>

HTH

Answer 2

有关一些视频介绍，请查看 DimeCasts.net。

我喜欢 Ioc 的两个主要原因：

1. 更容易的单元测试。
2. 更容易交换后端数据进行测试。假设您有一个 IPersonRepository。您的代码实现了一个从数据库加载数据的 PersonRepository。但是，如果数据库中没有任何数据或者数据库尚未设置怎么办？您可以使用 IoC 实现 DummyPersonRepository，它将从其他位置加载数据，例如 XML 文件或硬编码数据。

Answer 3

我认为当您了解为什么以及何时使用 IoC/DI 时，您就会开始掌握 IoC/DI 的内容。我不会太担心使用哪个 IoC 容器。您本质上可以自己编写一个基本容器（在最基本的级别上，它只是一个将接口映射到具体实现的字典）。 这里是一个很好的视频，展示了如何完成此操作。

核心概念是它鼓励组件的松耦合，这意味着代码更容易测试并且不依赖于其他具体类。

此链接包含有关 SOLID 原则的详细信息，您的问题特别与“D “（依赖倒置原理），但其他原理也会引起人们的兴趣。