多页应用程序的 MVC 与 Web API。未来的 Web API 是什么？答案

【问题标题】：MVC vs Web API for Multi Page App. Is The Future Web API?多页应用程序的 MVC 与 Web API。未来的 Web API 是什么？
【发布时间】：2015-09-05 16:52:05
【问题描述】：

我正在超早期故事阶段开始一个新项目，我有点不确定要使用什么设计模式。该应用程序是一个报告应用程序，允许用户设计报告并下载它们。该应用程序基本上是一个向导风格的多页数据选择器。我也想提供从桌面应用程序构建这些报告的功能。

考虑到过去几年 Web API 的进步，不使用它而不是 MVC 会不会很疯狂？

我已经离开开发游戏一段时间了，对于希望专注于服务器端业务逻辑的新应用程序开发人员以及作为尽可能多的消费前端。除了设置等之外，这个应用程序中几乎没有数据持久性。

那么我选择 Web API 路线是否正确？这是什么时候不使用 MVC 的一个很好的例子吗？或者我有一个中间立场，使用这两种方式被普遍理解为一种明智的设计选择？

【问题讨论】：

【解决方案1】：

这是一个很难回答的问题，因为它引发了更多问题。

简而言之，答案是：视情况而定。

如您所知，MVC 是一个用于分隔应用程序关注点的模式。另一方面，设计模式是软件设计问题的解决方案。

最初引入 Microsoft 的 asp.net MVC 品牌是为了为 webforms 提供替代。当您想要创建网站或 Web 应用程序时，这两种模式 (webforms and MVC) 都是可行的解决方案。这一切都取决于需要做什么以及您的团队在其中任何一个方面的效率。

Microsoft asp.net Web API 是一个在 .NET 框架之上构建 web APIs 的框架。过去，我们会使用.asmx 文件创建Web Services。然后，他们介绍了WCF，现在，我们有了Web API。

Web Services 和 WCF 今天仍然存在并且是有效的选择，但是......新的东西确实克服了早期东西中的一些限制。有Pros and Cons 在使用它们中的任何一个。您需要确定其中一个提供什么优于另一个，以及它是否符合您的需求。

该应用程序是一个报告应用程序，允许用户设计报告和下载它们。该应用程序基本上是一个向导风格的多页面数据选择器。我想提供构建这些的功能来自桌面应用的报告。

不清楚的是，当您说设计报告的能力时。您的意思是您的用户可以选择他们希望报告的外观和感觉的位置和方式吗？例如，用户 1 想要其徽标位于右上角，而用户 2 想要其徽标位于左下方等等...您的用户能够“设计”他们的报告多少？

然后你提到了一些关于巫师的事情。您的向导中的步骤是帮助用户设计他的报告，还是那里的步骤充当参数到您的报告？

然后你提到你想在Desktop 应用程序中提供这个类似向导的功能......我的第一直觉是host 你的网络应用程序的某个地方和你的Desktop应用程序，有一个 browser control 指向您的类似向导的 Web 应用程序的 URL。

考虑到过去几年 Web API 的进步，会不会不通过 MVC 使用它是不是疯了？

嗯...它们有不同的用途。

在过去几年中，您通常使用webforms 和/或asp.net MVC 创建了一个网站，以便设计网页/视图，然后将其发送到用户的浏览器。

Web APIs通常用于创建不返回视图或网页而是返回 data 的 API。

注意我通常的使用方式...这是因为过去 2-3 年的趋势一直是创建 @987654343 @ 并使用诸如Angular 之类的客户端框架来调用Web API 并渲染Views。使用这种方法，您几乎不需要使用asp.net MVC 和/或webforms。

请记住，虽然我说的是趋势，但我并不是说这会在未来几个月或几年内消失。创建这些类型的应用程序是有价值的，这超出了本文的范围。但请记住，客户端框架要求人们了解它们……因此，如果您选择走这条路，则需要考虑到这一点。

顺便说一句，微软确实引入了另一种 asp.net MVC 替代方案，称为 SPA (Single Page Application)，它允许您使用上述方法构建 Web 应用程序。

尽管如此，我什至不确定我是否最终回答了你的问题 :-)

我想我仍然需要对手头的确切任务进行更多说明。

【讨论】：

【解决方案2】：

嗯，MVC 和 Web API 方法都允许将模型和逻辑与表示分离，这符合您让向导通过桌面应用程序和 Web 工作的要求。对我来说，这取决于您对开发时间与应用程序性能的要求。

使用 MVC 会更快，但是除非您在视图中使用某种基于 AJAX 的专有控件，否则您将需要往返服务器。仅使用 Web API，您将需要进行大量手动 JSON 操作并更多地依赖前端 MVVM（MVC 模式的客户端表示），这始终更耗时。

使用 Web API 肯定会让您的耦合更加松散，有可能获得整体最高性能，如果您需要向公众发布您的 API，那么您已经做好了准备。不过，这将以开发时间为代价。

因此，如果您只是想快速启动并运行某些东西，我的建议是使用 MVC。需要一个非常松散耦合、性能最优的解决方案？走 Web API 路线。无论如何，微软现在几乎将 Web API 和 MVC 合并，因此 Web API 本质上是 MVC 模式的控制器。

我还应该补充一点，关于 Vlince 的回答，单页 Web 应用程序只是一个在客户端使用多个 DOM 元素的应用程序，这些元素根据输入显示或隐藏。 Kendo UI 是一个特别适合这种方法的框架，但是它只能使用纯 JavaScript 来完成，并且不是 Microsoft 特定的技术。

【讨论】：