我刚刚完成了Scott Gu的Nerd Diner教程。我发现它非常有用，因为它不仅教授了ASP.Net MVC的基础知识，还介绍了如何使用存储库，验证，单元测试，Ajax等。非常好，但仍然可以管理。
但是，我很好奇他的网站结构：
具体来说，他对每个物体使用了这种视图结构：
/ ModelObject /编辑/
/ ModelObject /创建/
然后提取两个视图之间的公共元素并将它们放入部分视图中。
我理解逻辑，但如果你的数据库中有一个中等数量的表，它似乎会导致“查看爆炸”。
斯科特真的很好，所以我假设他的结构是对的。但我想知道原因。谢谢！
[编辑澄清]
我意识到很多时候需要有多个动作（和视图）来处理创建和编辑中的差异。这是非常简单的编辑和创建的情况，其中两个动作之间的唯一区别是在一种情况下模型具有ID并且需要更新，而在另一种情况下模型没有，因此它需要是插入
在这种情况下，是否通过使用相同的视图处理导致重大问题的两种情况违反了“哑视图”规则？
答案 0 :(得分：6)
视图结构基于控制器，而不是模型。在Mvc方法中，您应该在控制器中查看每个操作（本质上是每个公共方法）。控制器操作不必直接与数据库中的每个表匹配，但数据库中的表数与控制器和视图的数量之间可能存在某种直接关系。控制器更高级别
在适用的控制器上进行CRUD类型操作是标准的：
这些操作中的每一个都需要一个视图（有时候不止一个）。
所以，是的，如果它是一个大型应用程序，你可以收集大量的视图。最小化代码的方法是：
重要的是要指出任何大型应用程序都会有很多形式。无论是Mvc还是Web Forms，如果有大量数据可供使用，那么必须有很多形式。
答案 1 :(得分：2)
确实，这确实适用于很多观点。但是，我发现在我的实际应用程序中，我会有许多表格与CRUD操作没有1：1的相关性。虽然我当然有数据进入这些表，但我发现大多数情况下，一个视图显示来自至少两个（如果不是三个或更多）表的数据。就像其他所有应用程序一样，你必须知道你所追求的是什么，以便你可以计划出来。任何大型应用程序都需要预先进行相当多的规划（包括分析MVC的视图/控制器数量）。
根据你的预感和过去的经验，这只是你可以拼凑在一起的小应用程序。
答案 2 :(得分：1)
如果你有asp.net webforms开发人员的背景，你的答案很自然。 有几个问题，这取决于观点。首先，使用asp.net-mvc，我们没有完全配备的服务器控件为我们制作许多东西，而没有真正意识到他们做了什么。现在你必须输入更多的代码，并且像html上的外科医生一样。这样我就可以找到一个合理的问题来查看“查看爆炸” 其他项目或多或少遵循该结构，请参阅Rob Conery的项目： Mvc Storefront
PS：“Skinny控制器，Fat Model和...... Dumb view”
[更新对澄清的回应]
嗯......我认为没有违反“愚蠢的观点”。重要的是，所有视图都与业务逻辑层或模型中的代码无关。你可以有一个“保存”按钮，控制器必须知道必须执行，插入或更新哪个动作。
答案 3 :(得分：1)
更多的反思，这就是我的想法：
在简单模型上组合编辑/创建视图很容易，因为
但这样做会强迫您
当使用单独的操作和单独的视图与提取到部分的公共代码分开时，这两个选项看起来都很丑陋且不必要。