我的应用程序部分需要用户验证，这可以自动完成（使用存储为cookie的现有刷新令牌）或手动使用登录表单。
虽然我可以使用服务实现这一点，但它感觉相当hackish（各种服务旨在返回数据）。但我想不出更好的方法来在不同的控制器之间共享功能。
P.S 我确实检查了https://github.com/witoldsz/angular-http-auth但是发现了401错误并启动了登录意味着我会拨打一个额外的电话，即使我知道它会失败。
答案 0 :(得分：3)
我认为你肯定可以将登录过程分解为服务，因为将信息存储并传递给应用程序中的各种控制器非常重要，这正是服务的用途。
我使用类似于您指出的链接创建了一个错误报告应用程序，但我也使用服务和控制器对其进行了自定义。这些是我在设置时遵循的步骤：
首先，我设置拦截器以捕获401错误和 广播需要登录的消息。
然后我设置了一个authService来记录所有那些坏的401调用。如果 有一个糟糕的电话，它被存储。
我还有一个登录控制器也使用authService 处理表格，注册，登录，注销等 控制器在每个页面的菜单中使用，所以没有机会 可能会错过广播事件。我的控制器在听 广播事件，并在收到时显示登录表单。
成功登录后，我告诉我的authService重复所有这些 存储的电话并将其删除。
现在这很好用，但如果有人刷新页面，删除了authService，拦截器将不得不再次完成所有工作，需要广播事件，最终会很痛苦。为了解决这个问题，我在登录控制器中进行了简单的检查。
首先检查authService是否存储了用户对象。
如果没有，请检查服务器，如果结果是用户已登录，则再次填充authService。
如果用户未登录，则不执行任何操作，但让authService知道您已对服务器进行了检查，并发现该用户未登录。
同样，在我的情况下，除非他们试图执行需要登录的特定操作，否则我不想强制用户登录。作为一个错误报告应用程序，我想允许匿名用户阅读内容，但是一旦他们要发布，他们就必须注册或登录。
如果您的案例涉及100％的时间登录，您可以完全忽略拦截器。只需设置一个服务和一个控制器。如果登录控制器发现未填充authService，则重定向到登录屏幕。刷新后，对服务器进行简单检查以确保它们仍然登录，否则重定向到登录屏幕。
答案 1 :(得分：3)
在这种情况下，服务非常合适。正如this video中关于最佳实践所述，服务并不像“获取数据”那么多，因为它是逻辑与控制器的分离。控制器说要做什么，服务说如何做。
因此，在您的情况下，控制器说“我需要检查用户是否经过身份验证”，但知道如何执行此操作，这取决于服务。
这也非常适合数据收集概念。控制器说“我需要获得所有员工信息”。该服务定义了如何。
他在本次会议中特别指出，每当需要在控制器之间共享信息时，服务几乎总是最好的方式。