菜单链接抑制是视图还是控制器的责任？

Question

在ASP.NET MVC中，我正在构建一个网站，要求主菜单（出现在每个页面上）应该删除条目的超链接（只留下文本），如果当前页面是链接到的那个。

菜单html在站点的母版页中定义，但当前是从控制器传递的ViewData填充的。这是设置的，以便基本控制器定义链接对象的字典，然后控制器上的操作从字典中获取相关条目，将地址设置为空。然后，基本控制器将其作为IEnumerable<>传递给视图。

然而，以批判的眼光看待它，感觉更像是视图应该自己负责的事情：菜单不会改变，所以控制器感觉就像它在不应该的地方对接。我唯一的一点保留意见是View可以了解当前页面的内容，这更像是一个控制器问题。

我现在一直在脑子里争论一段时间，所以我想对此提出一些其他意见。我原以为这会是一种相当常见的情况吗？

（最后一个澄清我的问题：主菜单链接到网站各个区域的“登陆页面”（基本上是所有控制器的索引操作），一旦你导航到该区域并且是在着陆页面上，菜单中的所有条目都将被链接）

Answer 1

我们可能会认为视图非常愚蠢，因为他们唯一的任务是将控制器提供的数据转换为客户端可以解析和显示的内容。

然而事实上，大多数视图（当然是我所见过的所有ASP.NET-MVC的例子）相当多的应用程序逻辑体现在视图中，它的视图决定了用户如何在应用程序中导航。如果不是包含代码的视图创建可点击的链接，图像和按钮，我们就没有太多的应用程序。

因此，具有控制内容的菜单的视图不违背关注点分离的精神。 OTH，一个控制器提供一些从列表转为菜单也是可以接受的。在这种情况下，您可能希望控制器指示菜单的哪些成员可以单击，此场景中的视图角色将执行控制器的愿望。

Answer 2

我会去创建一个菜单显示控制器。我认为，在视图中加入太多逻辑会使维护变得更加困难。

由于某些原因，不显示他不能使用的用户manu条目是应用程序逻辑的一部分，而不是视图本身。我总是试图把视图视为代码的一个愚蠢的部分，它只是做了所需要的 - 循环，基本的显示相关的ifs，这样的事情。

同样将足够重要的数据传递给视图可能会使应用程序更容易测试。

Answer 3

我同意AWJones它有点灰色区域，但是如果视图应该负责显示某些内容以及控制器是什么，那么菜单的内容就在控制器的域中。

我觉得菜单部分的“抑制”应该完全隐藏在视图（和最终用户）之外 - 视图应该得到它所需要的而不再是。