代码之家  ›  专栏  ›  技术社区  ›  mathieu

MVC:控制器责任

  •  2
  • mathieu  · 技术社区  · 14 年前

    对于以下控制器操作(在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注入到我的控制器中的。

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

    2 回复  |  直到 11 年前
        1
  •  1
  •   djna    14 年前

    如果这是您需要的处理,那么没有其他选择,它们作为操作的一部分发生。

    问题可能是重构是否合适。例如,检查用户的访问权限应该由谁负责?这里,action类进行检查,mydomain对象似乎允许任何人读取其内容。

    同样,对正在完成的工作流的检查:如果操作的代码忘记进行检查,会发生什么?

    我的感觉是,在当前的设计中,当扩展到许多动作方法时,

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

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

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

        2
  •  1
  •   Paul Hadfield    14 年前

    在我看来,这是一个干净的设计,应该“容易”维护。它可能是一个国际奥委会的候选人,以帮助测试等,所以你不是创造一些具体的实例,你正在使用的对象,但它看起来很好(再次国际海事组织)。

    我通常会研究“Web”操作对于其他技术(如Windows窗体)的可移植性。因此,在这种情况下,如果您要将主代码移动到另一个应用程序中,您的“用户”可能会得到不同的解决,如果他们没有得到授权,操作肯定会有所不同,所以我认为可以单独打电话。然后是主处理,再次很好地分离。最后,然后,直到那时,您才映射返回到一个不错的视图模型中的业务对象。

    如果没有别的,那么当问题被暴露/识别时,它是一个非常好的、干净的起点。