angularjs业务逻辑

Question

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

从可维护性和安全性的角度来看，这不是一个糟糕的实践吗？

Answer 1

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

Maintainability

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

业务逻辑

老实说，我从来不明白为什么开发人员在谈到他们的业务逻辑时会如此沉默。在他们的脑海中，似乎只要有人对他们的代码进行反向工程，他们就会发现一些他们从未想过的神奇的现实--他们将见证开发人员的天才！--并且现在将有足够的武器来实施一些市场攻击性的行为。

这太荒谬了。他们可以看到你的服务；他们可以看到你的用户界面；他们知道目标。如果他们想复制你，他们已经可以了。令人难以置信的是，我们的业务逻辑是我们产品的关键。在99%的情况下，这并不是一个问题。

而且，任何处于业务中心的大型复杂算法都不会最终出现在客户端，对吧？我们使用map/reduce操作和语义图在我们的分布式文件存储上做了大量的提升……

安全

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

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

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