asp.net-mvc - 让我的 MVC 更上一层楼 : DI and Unit of Work

Question

我研究过像 Nerddinner 和 ContactManager 这样更简单的应用程序以及像 Kigg 这样更复杂的应用程序。我了解简单的，现在我想了解更复杂的。

通常，较简单的应用程序在 LINQtoSQL 或 Entity Framework 之上具有存储库类和接口(interface)(尽可能松散耦合)。从 Controller 调用存储库以执行必要的数据操作。

当我检查更复杂的应用程序(如 Kigg 或 Oxite)时，我看到的一种常见模式是引入(我在这里只是触及表面，但我必须从某个地方开始):

IOC DI(以 Kigg 为例)

Web 请求终身管理器

工作单位

以下是我的问题:

我知道，为了真正拥有松散耦合的应用程序，您必须使用 Unity 之类的东西。但似乎在您将 Unity 引入组合的那一刻，您还必须引入 Web 请求生命周期管理器。这是为什么？为什么像 Nerddinner 这样的示例应用程序没有 Web 请求生命周期管理器？它究竟是做什么的？它是 Unity 特有的吗？

我注意到的第二种模式是引入工作单元。同样的问题:为什么 Nerddinner 或 ContactManager 不使用工作单元？相反，这些应用程序使用 Linq2Sql 或 Entity Framework 之上的存储库类来执行数据操作。没有任何工作单元的迹象。它到底是什么，为什么要使用它？

谢谢

下面是 Nerddiner 在 DinnersController 级别的 DI 示例:

    public DinnersController()
        : this(new DinnerRepository()) {
    }

    public DinnersController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }

那么我是否正确地假设由于第一个构造函数 Controller “拥有”DinnerRepository，因此它将取决于 Controller 的生命周期，因为它在那里被声明？

Answer 1

直接使用 Linq-to-SQL，您的 Controller 拥有对数据上下文的引用。它通常是 Controller 内部的私有(private)引用，因此是作为其构造的一部分创建的。生命周期管理没有必要，因为它在一个地方。

但是，当您使用 IoC 容器时，您的数据存储库是在您的 Controller 之外创建的。由于为您创建它的 IoC 容器不知道您将如何以及多久使用创建的对象，因此引入了生命周期策略。

例如，数据上下文(存储库)通常在 Web 请求开始时创建并在结束时销毁。但是，对于与外部 Web 服务或某些静态映射器(例如记录器)一起使用的组件，无需每次都创建它们。所以你可能想说只创建一次(即单调生活方式)。

这一切的发生是因为 IoC 容器(如 Unity)旨在处理多种情况，并且它们不知道您的具体需求。例如，某些应用程序使用 NHibernate(或 Entity Framework )可能会在多个页面/Web 请求期间持续的“对话”事务。 IoC 容器允许您调整对象的生命周期以满足您的需求。但正如所说，这是有代价的——因为没有单一的预定义策略，你必须自己选择一个。

为什么 NerdDinner 和其他应用程序不使用更高级的技术仅仅是因为它们旨在演示 MVC 功能，而不是其他一些库的高级用法。我记得有一篇文章展示了一个 IoC 容器的高级功能——这篇文章打破了一些被认可的设计模式，比如关注点分离——但这并不是那么重要，因为设计模式不是这篇文章的目标。与简单的 MVC 演示应用程序相同 - 他们不希望您，MVC 新手，迷失在 IoC 迷宫中。

我不建议将 Oxite 作为设计引用示例:
http://codebetter.com/blogs/karlseguin/archive/2008/12/15/oxite-oh-dear-lord-why.aspx
http://ayende.com/Blog/archive/2008/12/19/oxite-open-exchangable-informative-troubled-engine.aspx