有angular度的服务和浏览

我正在使用AngularJS进行SPA，而我正在使用browserify来构build我的应用程序。 现在问题出现了，我们应该以传统的方式来编写Angular服务，还是只require它们。

由于Angular服务是单例，因此可以很容易地通过require来完成：简单地暴露一个对象文字，就完成了。 工厂也是可能的，只是暴露一个function。 等等 …

我目前唯一的缺点是我无法从这样的文件（例如$http ）访问其他真正的 Angular服务，但在后台浏览，这似乎并不重要。 例如，你可以很容易地使用Node.js的http模块，这要归功于browserify。

那么你怎么看待这个？ 这有什么其他的优点和缺点？

PS：请注意，我不是在问这是好还是坏，因为这可能主要是主观的。 我感兴趣的是有哪些机会出现，或者我要面对哪些风险。

Answer 1

这样做的一个缺点是编写unit testing。 如果你仅仅是要求他们而不是使用Angular的dependency injection，那么很难嘲笑你的依赖。

对我来说，这是一个有点破坏者，因为使用Angular的许多好处之一是框架的可testing性。

Answer 2

这不好。

只需使用browserify最初加载所有您需要的模块。

• 你错过了$ httpBackend
• 你的代码变得难以遵循，也就是说，很less重用这个指令控制器
• 你错过了$ http拦截器
• 你错过了能够修改和与其他注射剂相互作用。

我只使用browserify / webpack / requirejs在一个angular度的应用程序是两件事情：

• 创buildjs包
• 将模板作为string注入angular模板caching中作为模块。

就个人而言，这种方法只是一个毫无意义的复杂function。

Answer 3

如果你需要诸如$http类的东西，那么在testing过程中就不会有任何方法来注入这些服务的虚拟/模拟。

虽然在某个地方你会做你需要$http的超级服务和你需要的地方之间的连线 。

我想到的第一件事情就是在路线上的parsing器 。 你甚至可以用一些辅助方法来处理多次声明相同的依赖关系。

想象一下这个模块：

 function SuperResource($http, pathExpression) {} exports.SuperResource = SuperResource; exports.superResourceFactory = function(pathExpression) { return [ '$http', function() { return new SuperResource($http, pathExpression); }]; }; 

你会做的地方：

 var myModule = require('./myModule.js'); resolvers: { usersResource: myModule.superResourceFactory('/users') } 

甚至你可以有一个用户模块来定义用户资源：

 var myModule = require('./myModule'); exports.userFactory = ['$http', function() { return new myModule.SuperResource($http, pathExpression); } 

是的，这些angular度特定的助手在其他angular度的免费代码，但至less他们是孤立在自己的方法/名称。