是否每个表都有一个单独的控制器需要在系统中进行操作？
例如，在设计内容管理系统的管理部分时，是否应该有一个单独的控制器来配置每个查找域，如下所示：
/DataTypeA/List --list for A
/DataTypeA/Create -- create new data
.
.
.
/DataTypeB/List --list for B
或者应该在Admin控制器中单独执行如下操作
/Admin/DataTypeA -- this lists DataTypeA
/Admin/DatatypeB -- this lists DataTypeB
/Admin/DataTypeA_Create -- Create a new DataTypeA
/Admin/DataTypeB_Create -- Create a new DataTypeB
答案 0 :(得分：3)
我的方法是为系统中的主要角色（表格）创建一个新的控制器。辅助表最终由控制器开始更新，辅助数据与主表相关联。例如，我有一个用户控制器，并且有一个操作来更新与User控制器中的特定用户相关联的UserContact信息，而不是创建一个单独的UserContact控制器。
答案 1 :(得分：1)
我发现赌注的方式是，一旦你到达表示层（在这种情况下是web层），你应该逻辑分组，而不是技术上。如果您有Product和Category表，则可能需要创建Catalog控制器或Store控制器。这将有助于您重用大量代码并保持组织有序。
答案 2 :(得分：0)
基本上，这取决于您所追求的内容以及您希望如何组织代码。如果DataTypeA明显不同于DataTypeB（即动物与汽车），那么您可能想要使用不同的控制器。但是，如果DataTypeA是（或类似于）DataTypeB的子集，那么我将使用一个具有不同操作的控制器。
ASP.NET MVC是如此灵活，它非常酷，但不可否认，一开始，灵活性就像你淹死了一样。刚开始编写代码，如果你走错了路，你就会意识到。 MVC有一个学习曲线。跟着它。
答案 3 :(得分：0)
我认为这主要是设计选择。我不认为有一个明确的答案，虽然我想如果你坚持使用模式的字母，那么你会选择one-controller-per-datatype选项。
我开始组建一个小型原型博客系统，以便在不久前尝试使用ASP.NET MVC（遗憾的是仍然是WIP），我最终制定的一个设计决策是将Comment控制器包含在Post控制器中。然而，我只是在尝试了单独的控制器后才决定这一点。我认为这很有效，因为这两个概念紧密相连：如果没有博客文章，你就无法发表评论。