【发布时间】：2010-10-12 16:57:53
【问题描述】：
在 MVC 中，放置授权码的正确位置在哪里？
控制器？
模型？
在视图中？
到处都是？
【问题讨论】：
【发布时间】：2010-10-12 16:57:53
【问题描述】：
控制器！
您的视图应该只处理用户界面和显示 您的模型应该代表系统中的数据。 您的 Controller 应该处理系统工作方式的逻辑。
授权用户涉及获取视图提供的凭据，根据模型中的某种授权列表检查它们，然后执行检查。
这是在控制器中完成的： 从 View 获取用户凭据 if（与模型中的用户列表比较返回匹配） 授权用户 别的 拒绝访问
【讨论】：
我认为授权是一个跨领域的问题。应该在一个地方 - 可以在需要的地方以声明方式应用的方面。
【讨论】：
我投票赞成把它放在有意义的地方。我的大部分授权内容都是通过使用 AuthorizeAttribute 装饰控制器操作（甚至是一些控制器）来处理的——或者从它派生的属性。在少数情况下——比如我的菜单——我将授权检查放在视图代码本身中，而不是在每个控制器中计算它并在 ViewData 中传递标志。在某些情况下，模型的某些方面仅适用于特定角色，在这些情况下，我使用可以获取当前用户和角色并在那里进行检查的方法来扩展模型。
【讨论】：
型号。
控制器只是用于通过不同的方式进行切换。查看只是为了……查看。
所以你应该在模型层制作所有的授权码。理想情况下，一切都会正常工作。如果没有，那么控制器会将用户带到正确的登录框。
【讨论】：
如果您必须在 M、V 或 c 之间进行选择，C 是正确的位置。但是，我推荐一种架构，您的应用程序全部包含在库中，而 UI 只是一层薄薄的外衣。你最终从控制器调用堆栈，但代码不在控制器中。
在 MVC 中，模型只是一个模型，或者是“哑数据对象”，如果您愿意的话。它旨在保持状态，而不应指示行为。 View 是供用户交互的，也是“哑”的；视图处理 UI。控制器是行为所在的位置，或者在应用程序逻辑位于库中的情况下是行为的入口点。有意义吗？
【讨论】：
-
你对MVC的定义不正确。 MVC 中的 M 是最重要的部分，它不是一个哑数据对象。行为应该在 M 中，这是您的业务逻辑。我不清楚授权是否是业务逻辑的一部分。