Angular服务是否应该有状态？
Angular服务是否应该有状态？
最近，我和我的几个同事讨论了AngularJS服务是否应该具有状态。我们对此提出了一些赞成和反对的观点，我想听听其他人对这个问题的想法和反馈。在搜索过程中，我找到了这个链接，但似乎没有明确提到最佳实践。在非客户端世界中，服务不应该保持状态，但我开始认为在客户端可能是可以接受的，因为这是一个不同的问题。
服务保持状态的原因：
- 服务不会被多个线程访问。每个浏览器将拥有自己的服务实例。
- 允许服务只保持其关心的状态，而不是将其存储在rootScope中。封装。
服务不保持状态的原因：
- 服务不再是幂等的。调用函数可能会改变状态，因此在基于服务状态调用时可能会产生不同的结果。
- 我认为总体上这样更容易进行测试。
解决“服务保持状态”部分中问题#2的一种方法是在rootScope上设置一个包含应用程序当前状态的appState对象。然后所有的状态将被收集在一个位置，你只需要从中提取出你需要的内容在你的服务中使用。我发现了这个，并且想知道。
在AngularJS中，服务通过工厂函数进行传递。基本上，服务是可以包含一些状态（例如用于缓存或存储执行操作所需数据）的对象。
一个很好的解决方案是，服务（实际上可以是函数）返回包含状态的对象。
以$http服务为例：可以通过调用var x = $http({url:'...'});来获取该服务的实例。
然后可以通过var result = x.get()来调用。实际上，$http.get是这个操作的快捷方式。
ngResource也是一样的：使用服务可以获取包含一些状态的对象，该对象可以执行所需的操作。
因此，我认为这是最好的选择：从某种程度上来说，通过将可能被操作修改的状态移动到单独的对象中，而不是在服务本身中存储，可以避免“副作用”，但是该对象可以具有特定的状态，以便能够存储自定义信息（如身份验证信息等）。
关于$http和$resource的观点很好。另外，我喜欢你关于只存储那些不会被服务上的函数调用修改的状态的想法（也许在初始化服务时除外）。
在Angular中，是否应该让一个服务有状态(state)这个问题的出现，主要是因为服务在很多情况下确实需要持有状态。
举个例子，如果你有一个负责与API通信的服务，那么这个服务可以持有认证状态。
顺便说一句，在AngularJS服务中，幂等性(idempotence)可能并不重要 - 它们是单例的，所以本质上是有一些状态的。你可以（在某些情况下必须）在服务上创建幂等方法，但这是一个单独的问题。
关于持有认证状态的观点很好。至于使服务幂等，我是指像你提到的那样，创建幂等方法。感谢你的回答。
持有状态的一个好处是你可以使用引用变量。由于这个，你可以对一个复杂数据结构创建一个清晰的描述！
基于以上讨论，我们可以得出结论，一个Angular服务应该具有状态。通过持有状态，服务可以更好地管理与API的通信以及复杂数据结构的描述。
