为何选择SPA（单页应用）？

Question

受到John Papa在Pluralsight的视频的启发，我开始学习SPA。看起来很有意思。但是，在我完全进入之前，我想澄清一些问题。

1. 据我所知，SPA是瘦服务器，胖客户端应用程序。我认为这应该适用于像John Para所展示的小型应用程序。它是否规模？它有多大？有人有这方面的经验吗？

2. 在SPA中，您似乎使用JavaScript编写所有业务逻辑。这根本不是一个好主意吗？你如何隐藏业务“秘密”？

由于我的背景主要是在C＃/ WPF / .NET中，转移到JavaScript似乎非常困难（好吧，我在十多年前学到了一点JavaScript - 我讨厌它，再也没有碰过它）。由于我的知识有限，我遇到了几个问题。调试JavaScript似乎对我来说是一场噩梦。备受好评的组件Breezejs似乎仍处于早期阶段（例如它不支持UOW，不支持CascadeDelete，不支持枚举）。那么，我想知道这是跳进来的好时机吗？

Answer 1

直接提出您的问题：

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

调试JavaScript并不是那么糟糕。您可以使用内置工具（Chrome中的Inspect元素和Firefox中的FireBug等）。此外，还有许多有用的第三方工具可以帮助您进行调试。

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

Answer 2

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

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

Answer 3

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

但我确实认为Knockout Alone无法处理大型应用程序，因为它本质上是连接的。我建议像Backbone Marionete或Angular这样的合作。

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

有兴趣的人可以访问我的演示页面http：\ saqibshakil.github.io我已经在那里展示了我的一些工作。

Answer 4

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