3

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

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

（显然与 结合使用AuthorizeAttribute）

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

所以这需要干燥：

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

  2. ApplicationController 在 ASP.NET MVC 中是要避免还是要采用的东西？

4

2 回答 2

3

如果您发现自己在重复这个逻辑，那么 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)
{
    // ...
}
于 2011-04-09T06:48:32.627 回答
2

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

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

关于其他选项：

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

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

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

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

于 2011-04-09T02:09:11.803 回答