为啥选择 SPA（单页应用程序）？

Posted 2023-03-09

【中文标题】为啥选择 SPA（单页应用程序）？

【英文标题】：Why SPA (Single Page App)?为什么选择 SPA（单页应用程序）？

【发布时间】：2013-07-26 01:21:54

【问题描述】：

受到 Pluralsight 上 John Papa 视频的启发，我开始学习 SPA。看起来很有趣。不过，在我完全投入之前，我想澄清一些我的问题。

据我所知，SPA 是一个瘦服务器、胖客户端应用程序。我认为这应该适用于像 John Para 演示的小型应用程序。它可以扩展吗？它可以有多大？有人有这方面的经验吗？

在 SPA 中，您似乎使用 javascript 编写所有业务逻辑。这是个好主意吗？如何隐藏业务“秘密”？

由于我的背景主要是 C#/WPF/.NET，转向 JavaScript 似乎非常困难（嗯，我在 10 多年前学习了一点 JavaScript - 我讨厌它，再也没有接触过它）。由于我的知识有限，我遇到了几个问题。调试 JavaScript 对我来说似乎是一场噩梦。备受赞誉的组件 Breezejs 似乎仍处于早期阶段（例如，它不支持 UOW，不支持 CascadeDelete，不支持枚举）。所以，我想知道现在是加入的好时机吗？

【问题讨论】：

另外你为什么说它不支持工作单元？我有几个完全支持它的例子。

使用 1008 个 CPU 支持 1000 个客户端比使用 8 个 CPU 支持相同的人群效率要高得多...

@kadumel，你是怎么做到的？我观看了 John 的第一个视频，它使用了 UOW，但没有使用 Breeze。然后，在另一个视频中，他使用了 Breeze，但没有使用 UOW。我用谷歌搜索并找到了这个页面***.com/questions/15113804/…。

只需将元数据暴露给控制器。通过工作单元路由所有呼叫。保存对 uow 的更改。都是一样的。

我会试试...谢谢。

【参考方案1】：

直接回答你的问题：

由于服务器逻辑很薄，您可以使用某种云服务，它们的扩展性非常好。大部分逻辑将由用户的浏览器处理。 如果你依赖于客户，你应该小心。 HTTP 协议很容易被操纵。不要忘记您应该始终在客户端和服务器端执行验证逻辑！此外，“隐藏”验证和其他“秘密”逻辑应仅位于服务器上。

调试 JavaScript 并没有那么糟糕。您可以使用内置工具（Chrome 中的 Inspect element 和 Firefox 中的 FireBug 等）。还有很多有用的第三方工具可以帮助您进行调试。

如果您开始一个新项目只是为了自己使用，那么我建议您尝试 SPA 方法。如果您正在编写生产代码，您应该成为该领域的专家，然后尝试使用这些技术。

【参考方案2】：

关于 UoW，请查看 TempHire 示例。它演示了在客户端和服务器上使用 UoW 模式。

https://github.com/IdeaBlade/Breeze/tree/master/Samples/TempHire

【参考方案3】：

我已经研究了几个月。我的结论是为您的 url 使用带有 light path.js 或 sammy.js 的 Knockout。我使用带有标准 Visual Studio MVC（可以返回 Json）的 json 作为后端。 我还没有完成这个项目，但到目前为止一切都很好。它闪电般快速、优雅且轻巧。 远离框架。看看标准库：它们是如何编写的；你可以通过这种方式学习很多 JavaScript。最后使用 chrome 或 explorer 开发者工具进行调试。 祝你好运

【参考方案4】：

我相信 SPA 为业务密集型应用程序以及更简单的应用程序工作流程（例如 Facebook 的工作流程）提供了更好的框架。我曾使用多页应用程序来处理具有复杂工作流程的银行应用程序，处理所有事情并保持应用程序性能令人生畏。

但我确实认为 Knockout Alone 无法处理大型应用程序，因为它本质上是连接的。我会推荐像 Backbone Marionte 或 Angular 这样的项目。

我正在为开源社区构建大规模 SPA 开发框架，因此我相信这是正确的方向。

有兴趣的可以去我的demo page http:\saqibshakil.github.io 我已经在那里展示了我的一些工作。