asp.net-mvc - MVC 框架是否不适合丰富的页面设计？

Question

只是作为这个问题的前缀，我决定看看将我们的旧遗留系统(从 vb6、vba、vb.net 到 c#.net 的 40 多个程序)移动到使用相同 DAL(条形码终端和一个基于 Web 的系统)，因为我大部分时间都在修复 15 岁的 vba 程序中糟糕或不存在的业务逻辑。我最近构建了一个完整的 Entity Framework 模型，并使用了流利的验证，并且在使用了一段时间后对它感到非常满意。

这个小团队熟悉网络表单(但不是很熟悉)，但最近几天我探索了 MVC Razor。我喜欢 MVC 框架，直到我尝试开始尝试在同一页面上添加更多功能，然后复制我们最近放入 Web 表单的系统似乎非常困难。以前，我会急切地加载客户及其所有子实体，然后将其绑定(bind)到客户的单个页面，以便他们可以访问所有内容(这是他们想要的)，它工作正常并且不慢。从这个单一页面，我可以编辑他们所有的帐户详细信息/联系人/电子邮件/电话/工作。

我在 MVC 中完成和看到的所有示例都处理单个更新、单个编辑等，但您肯定不能将每个操作分离到一个新的 View /页面中吗？我可以将丰富的模型传递给 MVC 中的 View ，但是尝试更新所有不同的子实体会很痛苦。

这可能是 MVC 并非设计用于的确切设计，这没关系，如果 MVC 将成为一个更好的平台，我愿意对其进行调整，但是您打算如何处理添加这种复杂性？我见过的一些方法:

很多局部 View ？将子信息传递给他们(或 id 和延迟加载)？

我见过包装多个 <forms> 的方法围绕一切并以这种方式处理 Action 。

将几乎所有任务都分开

如果解决方案更轻量级且更易于维护，我将去研究我需要的任何东西，我只是想在早期阶段看看我是否在浪费时间。任何指向我应该问的正确问题的指针将不胜感激。

Answer 1

与现有的任何其他技术相比，ASP.NET MVC 在处理复杂页面方面或多或少都没有更好的能力。

当然，MVC 比 Web 窗体应用程序需要更多的低级工作，没有直接绑定(bind)支持，但在大多数情况下，这是一件好事，并且在呈现页面的方式上提供了更大的灵 active 。

MVC 的整体理念之一是让您对事物有更多的控制权，但这种控制会导致在大多数非平凡的情况下需要更多的知识和更多的努力。 MVC 提供了许多工具功能来加速琐碎的工作(例如创建基于标准表的 CRUD)，但是当您拥有复杂的模型时，您将不得不自己完成大部分工作。

这并不是说 MVC 不适合它，而只是控制和灵 active 需要权衡取舍，而您需要承担更多责任。

在您的情况下，您只需创建一个包含您想要的所有字段的 View 模型。然后，您创建表单来编辑这些字段。在您的 Controller 中，您将需要展开该 View 模型并在数据库中创建或更新必要的记录。这并不难，但它比 WebForms 数据绑定(bind)工作量更大。

您可以查看 MVC 的更高级工具(商业)，例如 Telerik 的工具，它们开发了更多类似数据绑定(bind)的界面，但 MVC 不是拖放技术，需要您连接并编写所做的事情的各种逻辑。

如果您需要拖放、数据绑定(bind)功能，那么不需要。MVC 不是正确的技术。但是 WebForms 也要求您接受许多妥协，并以多种方式束缚您的手脚。

你可以使用局部 View ，但我很少使用它们。我更喜欢使用 Editor/DisplayTemplates，因为它们负责正确命名表单字段，即使对于集合和复杂对象也是如此。如果您不小心，PartialViews 往往会有很多陷阱。我几乎只将它们用作花哨的包含，或者在使用 Ajax 时。

我不确定您所说的“将多个 <forms> 包裹在所有内容周围”是什么意思。您不能在 HTML 中嵌套表单，这是不合法的。如果您的意思是在表格的每一行周围放置一个表单，那也不是有效的 html在大多数情况下(在表格和 tr 之间放置表格是不合法的)。

如果您有一个可以询问的具体问题会有所帮助，含糊的反对意​​见无助于我们解决您的问题。