Angular 服务和 browserify答案

【问题标题】：Angular services and browserifyAngular 服务和 browserify
【发布时间】：2014-11-18 14:24:29
【问题描述】：

我正在将 AngularJS 用于 SPA，并且正在使用 browserify 来构建我的应用程序。现在问题来了，我们应该以经典方式编写 Angular 服务，还是简单地 require 它们。

由于 Angular 服务是单例的，这也可以使用 require 轻松完成：只需公开一个对象字面量，就完成了。工厂也是可以的，只需暴露一个函数。等等……

我目前能想到的唯一缺点是我无法从这样的文件（例如，$http）访问其他 real Angular 服务，但在后台使用 browserify这似乎不是那么重要。例如，借助 browserify，您可以轻松使用 Node.js 的 http 模块。

那么你怎么看这个？这样做的其他优点和缺点是什么？

PS：请注意，我并不是在问这是好是坏，因为这可能主要是主观的。我比较感兴趣的是出现了哪些机会，或者我必须应对哪些风险。

【问题讨论】：

标签： javascript angularjs node.js browserify

【解决方案1】：

这样做的一个缺点是编写单元测试。如果你只是需要它们而不是使用 Angular 的依赖注入，那么模拟你的依赖是很困难的。

这对我来说有点破坏性，因为使用 Angular 的众多好处之一是框架的可测试性。

【讨论】：

【解决方案2】：

这很糟糕。

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

你错过了 $httpBackend
您的代码变得更难遵循，也就是说，很少需要重用该指令控制器
你错过了 $http 拦截器
您错过了能够修改其他注射剂并与之交互的能力。

我在 Angular 应用程序中使用 browserify/webpack/requirejs 的唯一目的是两件事：

创建 js 包
将模板作为字符串作为模块注入到角度模板缓存中。

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

【讨论】：

“很糟糕。”不是一个有用的答案。造成这种情况的原因是什么？为什么你认为它很糟糕？有什么缺点？

【解决方案3】：

如果您需要 $http 之类的东西，您将无法在测试期间注入这些服务的虚拟/模拟。

虽然您将在需要$http 的超级骗子服务和您需要它的地方之间进行接线。

我首先想到的是路由中的解析器。您甚至可以使用一些辅助方法来处理多次声明相同的依赖项。

想象一下这个模块：

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 specific helpers in an other angular free code，但至少它们在自己的方法/名称中是独立的。

【讨论】：