MVC：控制器职责答案

【问题标题】：MVC : Controller responsabilitiesMVC：控制器职责
【发布时间】：2013-05-19 16:30:35
【问题描述】：

我对以下控制器操作有一些疑问（在 ASP.NET MVC 中，但这是一个更通用的问题）：

public ActionResult DoSomething( int id, IUser currentUser )
{
     var myDomainObject = businessService.GetDomainObjectById( id );

     if( !securityService.CurrentUserCanAcess( currentUser, myDomainObject ) )
     {
         throw new HttpException(403, "forbidden");
     }

     if( workflowService.IsWorkflowFinishedFor( myDomainObject ) )
     {
         return RedirectToAction( "OtherAction", identifier );
     }

     var myModel = entityToModelMapper.GetModel( myDomainObject );

     return View( myModel );
}

workflowService、securityService、businessService 和 entityToModelMapper 都通过 IoC 注入到我的控制器中。

我担心在同一个控制器操作中涉及安全、业务和工作流。可以吗？

【问题讨论】：

标签： asp.net-mvc model-view-controller architecture

【解决方案1】：

如果这是您需要的处理，那么别无选择，它们会作为操作的一部分发生。

问题可能是某些重构是否合适。例如，检查用户的访问权限应该由谁负责？在这里，动作类进行检查，而 myDomain 对象似乎允许任何人读取其内容。

类似地检查正在完成的工作流：如果操作代码忘记进行检查，会发生什么？

我的感觉是，在目前的设计中，当扩展到很多动作方法时，这个

编码员，请记住检查访问权限权限和工作流状态

这种逻辑很可能在许多操作方法中重现 - 这是一件坏事，我们有重复的代码。

因此我认为进行一些重构以将其推送到域对象中，或者合适的包装器是合适的。

【讨论】：

实际上，它是“真正的”代码，它位于控制器内部的包装方法中。但是对于安全性和工作流程，如果我有许多需要这些检查的动作和控制器，我会继续使用动作过滤器！

【解决方案2】：

IMO 这是一个简洁的设计，应该“易于”维护。它可能是 IOC 帮助可测试性等的候选者，因此您不会创建您正在使用的某些对象的具体实例，但除此之外它看起来很好（再次 IMO）。

我通常会关注“网络”操作对于另一种技术（例如 Windows 窗体）的可移植性。因此，在这种情况下，如果您要将主代码移动到另一个应用程序中，您的“用户”可能会以不同的方式解决，并且如果他们未经授权的操作肯定会有所不同，所以我认为单独调用很好。然后你有主要的处理，再次很好地分开。最后，只有这样，您才会将返回的业务对象映射到一个漂亮的视图模型中。

如果没有别的，这是一个非常好的干净起点，可以在问题暴露/发现时进行修改和修改。

【讨论】：