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