jquery - [HTML5 + jQuery](无 ASP.NET)+ WCF 是企业级 Web 应用程序的有效解决方案吗？

Question

为了获得一些见解，我们使用 ASP.NET Web 表单已有很长时间了。

我们也意识到 MVC 相对于 Web 表单的优势，但是正在考虑另一种选择，即绕过所有这些抽象层，直接从纯 .HTML 页面转到 WCF 服务。

没有 .ASPX，没有 .cshtml/.vbhtml，只有纯 .HTML 文件，以避免服务器端逻辑和呈现。这是一些人提出的想法，并且随着HTML5 及其特性。通过完全控制 HTML 来定位更多设备的能力也是一个驱动因素。

我知道从技术角度来看这是可行的——尤其是使用 jQuery 使事情变得如此简单——但我担心通过抛出整个服务器端抽象(web 表单中的代码隐藏、 Controller 和 View 绑定(bind))在 MVC 中)我们最终会做更多我们以前不必担心的管道。

问题归结为:

1. 这是一个合理的担忧吗？如果是这样，我们最终可能会采用哪种管道？
2. 抛开整个 ASP.NET 框架(从 Web 应用程序端)并仅依赖从纯 HTML 页面与我们的 WCF 服务的直接通信，我们究竟会失去什么？

注意:我使用了“企业级”这个词来强调这不是一个只有几个页面的简单网络应用程序，其中底层架构的最终决定是无关紧要的，我们在这里谈论的是大屁股应用程序:)

编辑:为了更加清晰，我们在这种方法中关注的主要领域是:

• 身份验证和授权 --> MVC 使用属性(例如 AuthorizeAttribute )以非常直接的方式处理此问题，但是这种“静态”方法意味着 WCF 必须处理 token ，加密/解密它们，并决定谁可以自己做所有事情，同时在每次通话中维护所有这些信息。 这是唯一的解决方案吗？

• 关注点分离 --> MVC 显然做到了这一点，而且做得非常好，我可以补充一下。然而，这种方法会强制您在 HTML 中显式写入需要调用的 WCF 函数。因此，您的表示层不仅处理要绘制的内容，它还在其中嵌入了调用什么来获取其数据以及如何在页面中分发数据的逻辑。这可能不是什么大问题，但相比之下，MVC 中的 ViewBag 使您可以选择将 WCF 服务 URL 作为动态属性，这意味着逻辑现在是 Controller 的一部分，而不是 HTML 页面。更改该逻辑可以完全免除浏览 HTML 页面的麻烦。

• Binding & Validation --> 我将这两个放在同一个篮子里，因为最终一旦 WCF 服务响应一个包含我的页面运行所需的所有信息的 JSON 对象 (包括验证规则)有人必须将它绑定(bind)到那些空闲控件。

希望思路足够清晰，提前致谢。

Answer 1

您还没有“抛弃整个服务器端抽象”，您正在以不同于标准 Web 应用程序的方式划分功能。服务器端抽象现在来自向表示层提供数据的 WCF 服务

您将需要使用 Web 样式 API 来返回 JSON 以使其易于使用 - 我建议为此使用新的 Web API，因为它可以让您对 HTTP 交互进行细粒度控制，而这在以前的版本中有些隐藏WCF 中的 REST 实现

显然走这条路并不是 Elixir ——你仍然需要关心往返和延迟(让你的网络用户界面的复合部分单独调用后端数据最终会很容易页面呈现速度非常慢)。但从架构上讲，没有理由认为这种方法比传统 Web 应用程序的限制特别少。

可能的一个缺点是，对于每个页面，至少有两次往返 - 一次获取 HTML + JS，另一个用于 JS 获取数据 - 对于传统的网络应用程序，只有一次往返实现和渲染页面时服务器端加载数据一样