什么时候可以在 AngularJS 中的 $rootScope 上存储对象答案

【问题标题】：When is it ok to store an object on $rootScope in AngularJS什么时候可以在 AngularJS 中的 $rootScope 上存储对象
【发布时间】：2014-04-11 17:56:27
【问题描述】：

我看到很多关于身份验证的教程都在 $rootScope 上放置了一个“auth”对象，包括来自 FireBase-people 的 AngularFire-seed。

我认为将对象放在根作用域上是一种不好的做法，而应该创建一个服务。为什么在身份验证方面（显然）没问题？或者更确切地说是一个更普遍的问题：什么时候可以将某些东西放在 rootscope 上，甚至是好的做法？

再举一个例子。我还有一个关于用户的配置文件对象。也可以将它添加到 auth-object 中吗？在这种情况下，我什至不会污染 rootscope，因为 auth-object 已经存在。可以像这样（通过 auth-object）将配置文件放在 rootscope 上吗？如果不是，为什么？

我知道，这是几个问题，但它们都归结为标题中的一个问题......

【问题讨论】：

我没有将整个 auth/session 对象放入 rootScope。我更喜欢将应用程序级控制器附加到，它提供调用包含身份验证数据的服务的范围方法。这样，它基本上仍然是“全局的”，但不在 rootScope 中。现在考虑到客户端拥有你所有的应用程序，与 rootScope 相比，在服务中拥有东西并不是更好或更安全，我认为它归结为你想要访问数据的位置和方式。将东西放入 rootScope 可以让它们从您的视图中全局访问。
如果数据对所有作用域真正通用，那么 $rootScope 是一个完全可以接受的放置数据的地方。
不错的 rootScope-altnerative @aet。我可能不会使用它，但很高兴知道替代品。

标签： angularjs

【解决方案1】：

很可能是因为原型继承在 JavaScript 中的工作方式。

例如：客户端需要整个应用程序的身份验证凭据，有什么比$rootScope 更好的地方？（除非您希望在服务中使用它并在所有工件中注入该服务）。这就像一个 ASPECT 来解决携带身份验证数据的横切功能。通过在$rootScope 中添加身份验证相关数据，您可以轻松地从显然继承自$rootScope 的任何scope 获取身份验证详细信息（由于原型继承）。

这适用于 not 具有孤立作用域的指令，但对于孤立作用域而言，由于您获得了有效的 2 向绑定机制，因此要攀登的墙会很小。

【讨论】：

谢谢，也谢谢大家的意见 :) 对我来说，实际的结果是我会将 auth/session 对象放在 $rootScope 上，因为它几乎会在所有页面上使用，但我的profile-object 我不会添加到这个 auth/session-object 中，因为我只会在几个页面/视图上使用它（实际上，它将通过标题在所有页面上可见（如“Hi，EricC”），但标题是单个模板）。
有人可能只是在更近的范围内重命名变量，这可能会隐藏根范围。依赖于这样的东西对于大型应用程序来说并不好。无论如何都必须在任何地方注入 rootscope 以避免这种冲突，那么为什么不创建一个全局服务或常量呢？
确实有cmets不会污染rootscope。但是我没有得到任何关于为什么我们不应该污染 rootscope 以及这背后的原因的细节？