Question

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

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

（显然与AuthorizeAttribute一起使用）

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

所以这需要干涸：

我应该写一个ApplicationContoller，其中所有其他控制器都继承并公开User属性，或者我应该将其添加到IAdminService并将其作为方法公开？
在ASP.NET MVC中，ApplicationController是否应该避免或拥抱？

Answer 1

如果您发现自己重复此逻辑，那么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);
    }
}

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

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

Answer 2

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

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

关于其他选项：

在IAdminService中公开它可以为您提供额外的好处，可以在其他地方使用，而不仅仅是在Controller中。这是一个加号。请确保您不会过多地混乱您的界面。

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

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

无论你做什么，你仍然可以在界面中添加一个方法，并在基础控制器的User属性后面抽象它。

干燥ASP.NET MVC操作：ApplicationController还是Service？

2 个答案: