angularjs - angularjs业务逻辑

Question

在 Angularjs 中，可以使用一个 restful 服务器 api 来存储所有嵌入在 Javascript 中的业务逻辑的对象。大多数例子似乎都指向了这个方向。

这在可维护性和安全性方面都不是不好的做法吗？

Answer 1

这个问题有点模糊，但我会尝试给出一个广泛的答案：我不认为将逻辑迁移到客户端是不好的做法。

可维护性

天哪！我的职业生涯是从后端开始的，我可以非常自信地说，代码是在前面还是在后面对它的可维护性没有影响；代码就是代码。无论我们将其放置在客户端的可重用服务组件中还是服务器上的可重用库中，变更管理都非常相似。有关重要的附加说明，请参阅安全部分。

商业逻辑

老实说，我一直不明白为什么开发人员在谈到他们的业务逻辑时会如此沉默寡言。在他们看来，如果有人对他们的代码进行逆向工程，他们就会发现一些他们从未想过的神奇现实——他们将见证开发人员的天才！- 现在将有足够的武装来实施某种市场侵略行为。

这是荒谬的。他们可以看到您的服务；他们可以看到您的用户界面；他们知道目标。如果他们想复制你，他们已经可以了。我们的业务逻辑是我们产品的关键，这是非常罕见的。在 99% 的情况下，这不是问题。

无论如何，业务中心的任何大规模复杂算法都不会最终出现在客户端上，对吧？我们使用 map/reduce 操作和语义图对我们的分布式文件存储进行了大量提升......

安全

一如既往，这是一个重要的考虑因素，但关键在于 REST API。REST API 是不可篡改的官方网关。如果我们的user模型需要一个first_name字段，那么 REST API 的工作就是确保该字段存在。我们可能还会在客户端引入检查，但这些检查几乎总是考虑到用户体验：同步和即时反馈优于异步和延迟反馈。

任何与严格定义的安全相关的东西都在服务器上。身份验证和授权显然在服务器上。他们从不在客户端。因此，我们不会通过选择单页应用程序范式来引入任何漏洞。想想 Twitter、Google 产品或 Facebook——它们都有开放的 API，我们可以使用这些 API 代替 Web 界面来实现相同的目标。API 执行关键规则，确保适当的安全性，但将用户体验留给客户端。

显然，这意味着一些逻辑在客户端和服务器上是重复的，比如基本验证。当然。但我们这样做是为了用户体验。它在我们的变更管理流程中引入了更多的复杂性，但它远远超过了用户体验的收益。