asp.net-mvc - ASP.Net MVC View 结构

Question

我刚刚完成了 Scott Gu 的 Nerd Diner 教程。我发现它非常有帮助，因为它不仅教授 ASP.Net MVC 的基础知识，还教授如何使用存储库、验证、单元测试、Ajax 等。非常彻底，但仍然易于管理。

但是，我对他的网站结构很好奇:

具体来说，他对每个对象都使用了这个 View 结构:
/模型对象/编辑/
/模型对象/创建/

然后提取两个 View 之间的公共(public)元素并将它们放入一个partial中。

我理解这个逻辑，但如果数据库中的表数量适中，它似乎会导致“ View 爆炸”。

Scott 真的很棒，所以我假设他的结构是正确的。但我想知道为什么。

谢谢!

[编辑以澄清]

我意识到很多时候需要多个操作(和 View )来处理创建和编辑中的差异。这是非常简单的编辑和创建的情况，其中两个操作之间的唯一区别是在一种情况下模型有 ID 并且需要更新，而在另一种情况下模型没有 ID，因此需要更新已插入。

在这种情况下，使用同一个 View 来处理这两种情况会违反“哑 View ”规则，会导致重大问题吗？

Answer 1

View 结构基于 Controller ，而不是直接基于模型。在 Mvc 方法中，您应该对 Controller 中的每个操作(本质上是每个公共(public)方法)有一个 View 。 Controller 操作不必直接与数据库中的每个表匹配，但数据库中的表数量与 Controller 和 View 的数量之间可能存在某种直接关系。 Controller 级别更高

在适用的情况下， Controller 上有 CRUD 类型的操作是标准的:

• 索引:列出项目
• 详细信息:查看特定项目
• 编辑:编辑项目
• 创建:新项目
• 删除:删除项目

其中每一项操作都需要一个 View (有时多个 View )。

所以，是的，如果是大型应用程序，您可以收集大量 View 。最小化代码的方法是:

• 将共享功能提取到部分 View 中，以使操作 View 尽可能小且简单
• 保持 View 和 Controller 简单，以便易于维护
• 使用 AJAX 在一个 View 中实现更多功能

需要指出的是，任何大型应用程序都会有很多表单。无论是 Mvc 还是 Web 表单，如果需要处理大量数据，就需要大量表单来完成。