ASP.NET MVC 和 IoC - 链接注入

Question

请温柔点，我是 IoC/MVC 方面的新手，但我正在尝试。我了解 DI 对于测试目的的价值以及 IoC 如何在运行时解决依赖关系，并且已经完成了几个对标准 CRUD 操作有意义的示例...

我正在开始一个新项目，但无法想出一个干净的方法来完成用户权限。我的网站主要通过登录后具有功能（注册、常见问题解答、关于我们等除外）的任何页面来保护。我有一个自定义身份，它有几个控制数据访问的额外属性...所以...

使用 Ninject，我将一个具体类型* 绑定到一个方法 (Bind().ToMethod( c => MyIdentity.GetIdentity()); 这样，当我将 MyIdentity 添加到构造函数时，它就会根据方法调用的结果进行注入

。它适合（从 GetIdentity() 方法）直接查询请求 cookies 对象（通过 FormsAuthentication）吗？在测试控制器时，我可以传入一个身份，但是 GetIdentity()< /code> 方法基本上是不可测试的...

另外，在 GetIdentity() 方法中，我应该手动创建存储库的具体实例吗？

还是有更好的方法？

Answer 1

我认为您走在正确的轨道上，因为您从单元测试中抽象出了数据库通信和 ASP.NET 依赖项。不要担心您无法在测试中测试所有内容。您的应用程序中总会有一些不可测试的代码行。 GetIdentity 就是一个很好的例子。在应用程序的某个地方，您需要与特定于框架的 API 进行通信，并且单元测试无法覆盖此代码。

但可能仍有改进的空间。虽然未经测试的 GetIdentity 不是问题，但事实上它实际上可以由应用程序调用。它只是挂在那里，等待有人不小心调用它。那么为什么不抽象身份的创建呢？例如，创建一个抽象工厂，它知道如何为当前上下文获取正确的标识。您可以注入这个工厂，而不是注入身份本身。这允许您在应用程序的组合根附近和应用程序其余部分的范围之外定义一个实现。除此之外，代码更清楚地传达了正在发生的事情。没有人会问“我实际上得到了哪个身份？”，因为通过他们调用的工厂方法就可以清楚地知道这一点。

这是一个例子：

public interface IIdentityProvider
{
    // Bit verbose, but veeeery clear,
    // but pick another name if you like,
    MyIdentity GetIdentityForCurrentUser();
}

在你的组合根中，你可以实现这个：

private sealed class AspNetIdentityProvider : IIdentityProvider
{
    public MyIdentity GetIdentityForCurrentUser()
    {
       // here the code of the MyIdentity.GetIdentity() method.
    }
}

作为一个技巧，我有时让我的测试对象实现工厂和产品，只是为了在单元测试期间方便。例如：通过

private sealed class FakeMyIdentity
    : FakeMyIdentity, IIdentityProvider
{
    public MyIdentity GetIdentityForCurrentUser()
    {
       // just returning itself.
       return this;
    }
}

这种方式，您可以在需要 IIdentityProvider 的构造函数中注入 FakeMyIdentity。我发现这并不会牺牲测试的可读性（这很重要）。
当然，您希望 AspNetIdentityProvider 中的代码尽可能少，因为您无法（自动）测试它。还要确保您的 MyIdentity 类不依赖于任何框架特定部分。如果是这样，您也需要对其进行抽象。

我希望这是有道理的。

Answer 2

这里有两件事我会做一些不同的事情...

1. 我会使用一个自定义 IPrincipal 对象，其中包含您的身份验证需求所需的所有属性。然后，我将其与自定义 cookie 创建和 AuthenticateRequest 事件结合使用，以避免每个请求都调用数据库。

2. 如果另一个类中需要我的 IPrincipal / Identity，我会将其作为方法参数传递，而不是将其作为对其自身类的依赖项。
   当沿着这条路线走时，我使用自定义模型绑定器，因此它们是我的操作的参数，而不是神奇地出现在我的操作方法中。
   注意：这只是我一直以来做事的方式，因此请持保留态度。

抱歉，这可能引发的问题多于答案。欢迎就我的方法提出更多问题。