DRY-ing ASP.NET MVC 操作：ApplicationController 还是 Service？

Question

我正在编写一个 ASP.NET MVC 3 应用程序，我发现自己经常在我的操作方法中编写这行代码：

var user = _session.Single<User>(u => u.UserName == User.Identity.Name);

（显然与AuthorizeAttribute结合使用）

还有其他事情经常重复，但这是最突出的事情，我最终有 3 个操作彼此相邻，每个操作都需要检索授权用户。

所以这需要干燥：

1. 我应该写一个ApplicationContoller，所有其他控制器都从那里继承并公开一个User属性，还是应该将它添加到我的IAdminService并将它作为一种方法公开？

2. 在 ASP.NET MVC 中应避免或采用 ApplicationController 吗？

Answer 1

作为一个不太喜欢控制器超类型的人，我会考虑使用依赖注入并使用构造函数注入来“注入”用户。

o/c 这有一些缺点。这意味着您必须为控制器中的每次使用提供一个字段，并且还必须在您的 IOC 工具中创建一个绑定。这也假设您使用的是 IOC 容器。

关于其他选项：

在 IAdminService 中公开它会给您带来额外的好处，即可以在其他地方使用，而不仅仅是在 Controller 中。所以这是一个优点。请确保您的界面不会过于混乱。

一开始在基本控制器中使用它也很诱人，但我发现随着越来越多的功能被添加，控制器基本类型变得臃肿和管理不善，因为没有多重继承，人们需要其中一些和一些那...事情会变得丑陋。更不用说，如果您使用 AsyncController，您将需要管理两种基本类型。

基本上，在您的两个选项之间，我会使用界面。

无论你做什么，你仍然可以向接口添加一个方法，也可以将它抽象到基础控制器中的用户属性后面。

Answer 2

如果您发现自己在重复这个逻辑，那么 User 类型的自定义模型绑定器可能会有所帮助：

public class UserModelBinder : DefaultModelBinder
{
    private readonly ISession _session;
    public UserModelBinder(ISession session)
    {
        _session = session;
    }

    public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var username = controllerContext.HttpContext.User.Identity.Name;
        return _session.Single<User>(u => u.UserName == username);
    }
}

一旦您注册了 binder，您的控制器操作可能如下所示：

[Authorize]
public ActionResult Foo(User user)
{
    // ...
}