MVC：控制器职责
我对以下控制器操作有一些疑问（在 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 注入到我的控制器中。
我担心同一控制器操作涉及安全性、业务和工作流程。可以吗？
I have some doubts regarding the following controller action (in ASP.NET MVC, but it's a more generic question ) :
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 and entityToModelMapper are all injected into my controller with IoC.
I'm concerned about having security, business and workflow involved in the same controller action. Is it OK ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果这是您需要的处理，那么别无选择，它们作为操作的一部分发生。
问题可能是一些重构是否合适。例如，检查用户的访问权限应该由谁负责？这里操作类进行检查，并且 myDomain 对象似乎允许任何人读取其内容。
类似地，对正在完成的工作流程的检查：如果操作的代码忘记进行该检查，会发生什么？
我的感觉是，在目前的设计中，当扩展到很多动作方法时，这个
类型的逻辑很可能在许多操作方法中重现 - 这是一件坏事，我们有重复的代码。
因此，我认为进行一些重构以将其推入域对象或合适的包装器是合适的。
If this is the processing you need then there's no alternative, they happen as part of the action.
The question might be whether some refactoring is appropriate. For example, whose responsibility should it it be to check the user's access rights? Here the action class makes the check and the myDomain object seems to allow anybody to read its contents.
Similarly the check for the workflow being finished: if the code of the action forgets to make that check, what happens?
My feeling is that in the current design, when extended to many action methods, this
kind of logic could well be reproduced in many action methods - this is a bad thing, we have duplication of code.
Hence I think some refactoring to push that into the domain object, or a suitable wrapper is appropriate.
在我看来，这是一个干净的设计，应该“易于”维护。它可能是 IOC 的候选者，可以帮助测试可测试性等。因此，您不会创建正在使用的某些对象的具体实例，但除此之外它看起来很好（同样是 IMO）。
我通常会考虑“Web”操作对于另一种技术（例如 Windows 窗体）的可移植性。因此，在这种情况下，如果您要将主代码移动到另一个应用程序中，您的“用户”可能会以不同的方式解析，并且如果他们未经授权，操作肯定会有所不同，所以我认为单独的调用很好。然后是主要处理，再次很好地分开。最后，只有到那时，您才能将返回的业务对象映射到一个漂亮的视图模型中。
如果不出意外的话，这是一个极好的干净起点，可以在问题暴露/发现时进行修改。
IMO it is a clean design that should be "easy" to maintain. It may be a candidate for IOC to help testabililty, etc. so you are not creating concrete instances of some of the objects you are using but other than that it looks fine (again IMO).
I normally look at how portable a "web" action is to another technology (such as windows forms). So in this case, if you were to move the main code into another applciation your "user" may be resolved differently and the action if they are not authorised would definitely be different so I thnk that's fine to be a separate call. Then you have the main processing, again nicely separated. Finally, then and only then do you map the business object that's returned into a nice view model.
If nothing else, it is a fantastic clean starting point to go live with and modify as and when issues are exposed / identified.