StructureMap 2.6.1 和 ASP.NET MVC 2 问题（来自 DI 的完全初学者）

Question

根据在另一个线程上与 @Aaronaught 的对话，我已经开始将我的应用程序转换为使用依赖项注入和存储库模式，但我有点卡住了。我想我已经掌握了模式的大部分内容和流程，但我一直坚持将 StructureMap 实现到 ASP.NET MVC 2 中。我读过的示例似乎与我所使用的最新版本的 StructureMap 已经过时了。正在使用（2.6.1）。

我希望有人可以根据我在下面粘贴的代码来填补空白：

public static class Bootstrapper {
    public static void Configure() {
        ObjectFactory.Configure(x => {
            x.For<DataContext>().Add(new DataContext());
        });
    }
}

有了这个，我可以从我的控制器中获取 DataContext 的实例：

protected DataContext dc = ObjectFactory.GetInstance<DataContext>();

我知道这样做是错误的，但我很困惑关于如何避免它。继续，这是控制器工厂：

public class StructureMapControllerFactory : DefaultControllerFactory {
    protected override IController GetControllerInstance(
        RequestContext rc,
        Type ct) {
        return (ObjectFactory.GetInstance(ct) as Controller);
    }
}

我不明白它到底是做什么的，但它在示例中，所以我正在复制它。有人可以向我解释一下吗？

现在根据我的理解，应该有一些注册表，如果我理解正确的话，应该全球化对象实例，例如 DataContext。这是正确的吗？如果是这样，我该如何编写 StructureMap 2.6.1 的注册表？我看到的示例代码似乎已经过时了，因为当我编写它时，我没有可用的相同选项（通过 IntelliSense），所以我不确定如何编写它......

我将非常感谢任何帮助填补我的空白。

PS 我对依赖注入和存储库的体验总计大约 8 小时。

更新/结论

阅读了 @Pure 下面的精彩解释并观看了他在子评论中引用的 tekpub 视频后，我选择了 Ninject 而不是 StructureMap。

我不知道 Ninject 是否比 StructureMap 更好，但从我的角度来看，它绝对更容易开始使用。

Answer 1

好的，

我确信 Jeremy Miller 会更正我的帖子并为您提供事实如此，但是拥有使用 StructureMap 创建控制器的自定义 Controller 工厂 的想法是因为 Controller 类 是 关键类，其中大部分逻辑开始并发生（是的，有动作过滤器和之前发生的东西，但让我们保持简单） - 这需要预先拥有所有依赖项在任何逻辑开始之前进行设置。

所以想法是这样的。如果所有逻辑和魔法独角兽的东西都发生在控制器方法中，那么当我们第一次输入方法时......我们需要已经设置好所有要求。更重要的是，任何控制器中的每个方法都不应该关心它有什么要求（即实例）..只关心来自某个地方的某个人。 ..已经做出了这个决定，并给了我我们可能需要的所有重要物品。

这是 DI/IoC 的核心。

因此，让我们使用一些非常简单的代码来解释这一点，因为我不擅长解释事情。

---

假设我们在控制器中有以下方法：-

public ActionMethod Index()
{
   // List all Products.
}

非常简单。只是向浏览器列出一些产品。所以你需要问的第一件事是 ->什么是产品？它们来自哪里？嗯，控制器方法根本不会问这个问题。事实上，它并不关心他们来自哪里。它只关心它有某物，即产品。

所以当我们使用这种方法时，我们也不应该关心产品信息存在于哪里。我们只想用这个名为“产品”的东西做一些事情。

好吧..那么让我们用它做点什么...

public ActionMethod Index()
{
   var products = _myProductService.Find().ToList();

   // .. rest snipped.
}

好吧..到目前为止，我们现在要求一些服务来查找所有产品，然后列出它们。基尔。尽管如此，我们并不关心这些产品的来源。或者甚至，这个产品服务是什么。这就是关键-> 我们让 DI/IoC 来担心这个问题。我们所关心的是我们有一些ProductService，它可以对某些产品执行一些操作。在本例中，它将查找所有产品，然后我们要求它列出找到的所有产品。

那么 DI/IoC 在哪里发挥作用呢？

这是独角兽魔法部分:)

当这个控制器实例化时，它询问 StructureMap ：

“Oi！StructureMap！我需要创建一个
家庭控制器。但是 HomeController
至少有一个构造函数..并且
它拥有最复杂的构造函数（注意：
DI/IoC 称这是最贪婪的
构造函数）列出了一些
它需要的对象。所以...我
需要首先创建这些对象，
然后创建我的 HomeController .. 和
将这些对象传入。将这些对象传入。

让我们看一下代码...

public class HomeController : Controller
{
    private IProductService _productService;
    private ILoggingService _loggingService;

    public HomeController(IProductService productService, ILoggingService loggingService)
    {
       _productService = productService;
       _loggingService = loggingService;
    }

    public ActionMethod Index()
    {
        var products = _productService.Find().ToList();

        // rest snipped.
    }
}

哇——这里发生了一些事情。
让我们回顾一下 ->所以 StructureMap 说：

我需要一个 IProductService 和一个 ILoggingService 实例。我将其传递给 HomeController 构造函数
...你能给我那些吗？”

然后 StructureMap 说：

好的..首先-> IProductService。让我们看看这里，您已将 IProductService 映射到
您创建的自定义类，名为 ReallyFastProductService。库尔，我会创造出那些坏男孩之一。
接下来，您将 ILoggingService 映射到 NLogLoggingService 类...很好！
NLog wroxs，伙计。所以我也会创造一个坏男孩。好的，我现在已经做了这两个实例。
最后！我现在可以创建您想要的 HomeController 的实例..
然后我将把我刚刚创建的两个对象传递到 HomeController 构造函数中......还有中提琴！这是控制器实例。

...所以现在，你有了控制器实例。

....当您进入 Index() 方法时，如果您使用鼠标并将鼠标悬停在实例上，它们将是一个 ReallyFastProductService 和一个 NLogLoggingService。

惊人的！因此，这意味着 Index() 方法永远不会紧密耦合到类的特定实现。

现在，您认为您不喜欢在 ReallyFastProductService 中所做的所有代码，并决定编写另一代码，该代码使用了您刚刚学到的一些新技巧和技能。现在您创建了一个名为 PewPewProductService 的第二个类，因为它是 pwns 的。现在，如果您突然将 StructureMap 映射从...更改

ObjectFactory.Configure(x => 
    { x.For<IProductService>().Add(new ReallyFastProductService());});

为

ObjectFactory.Configure(x => 
    { x.For<IProductService>().Add(new PewPewProductService());});

...，那么 HomeController 中的所有方法现在都会引用您刚刚构建的新类中的逻辑。无需更改控制器中的任何代码。

抓住掉落的一分钱:)

欢迎来到 DI/IoC 以及它为何如此重要。