Angularjs 将模块定义为“服务”、“工厂”有意义吗？

在我们的一个angular项目中，我们定义了一些模块，如：

angular.module("services", [])....
angular.module("controllers", ['services'])....
angular.module("factories", [])....

然后根据它们制作一个主模块：

angular.module("app", ['services', 'controllers', 'factories'])

有些同事认为这种方式不好，他更喜欢按业务特性对模块进行分组，例如：

angular.module("login", [])....
angular.module("user-admin", [])....
angular.module("post-admin", [])....

然后将它们组合在一起：

angular.module("app", ['login', 'user-admin', 'post-admin'])

我认为他的方法是有道理的，但我不确定定义模块的最佳实践

---

定义模块时应遵循哪些规则？

有时，当我们开始使用AngularJS时，我们认为创建不同的模块是一个好主意，例如，为控制器、服务、指令等创建不同的模块……但这可能不是最好的选择。例如：假设我们在名为“myapp.controllers”的模块内创建一个控制器，该组件依赖于模块“myapp.services”内的服务。当我们想在另一个应用程序中使用该控制器时，我们不仅需要控制器模块，还需要服务模块以及作为依赖项的任何其他模块。但是，如果我们有一个登录模块，并且我们在模块“myapp.login”下创建控制器、服务、指令等，那么稍后当我们想要使用该模块时，我们将拥有我们需要使用的所有东西，而不需要其他依赖项

另一种方式

我们可以使用的另一种分解应用程序的方法是按路径划分模块。这种崩溃 允许我们编写专注于每个路由的功能的独立测试。通过can总线进行模块化 根据项目的不同，使其更有意义；它允许我们有效地划分我们的功能 当我们处理许多独立的路线时

angular.module('myApp.home', []);
angular.module('myApp.login', []);
angular.module('myApp.account', []);
angular.module('myApp', [
'myApp.home',
'myApp.login',
'myApp.account'
]);

当我们处理大量路由时，这种模块化特别有意义

---

和/或当我们在路线之间没有太多交叉时，

典型地，在我个人经验中，功能性分组最有效，这里有一些文档支持，也可以考虑使用打包器来打包组件。