我已经猴子修补了微风 EntityManager.prototype 以便它返回角度 $q 承诺，同时还调用 $rootScope.$apply （使用类似于Ward Bell 解决方案的代码）。
然而，这在一个重要方面存在问题：breeze 内部的代码使用failpromise 对象上的方法注册 errorCallbacks （例如 promise.then(callback).fail(errCallback)
该fail方法不是 CommonJS promise/A+ 规范的一部分，因此不包含在 angularjs promise api 中。结果是 EntityManager.prototype 现在返回的 angularjs 承诺没有 fail 方法，因此引发了异常。
问题：有没有一种方法可以定制breezejs，以便只支持CommonJS/A+ 规范中包含的promise api，而我不必直接修改breezejs 库本身？由于怀疑不是，所以我也提出了一个轻而易举的更改请求。
谢谢克里斯蒂安·克劳赫斯特
请不要EntityManager用 $q 修补微风原型。当你这样做时，你就违反了保修。只是不要。
Breeze 使用Q.js作为 Promise 并且 Q 是 CommonJS 兼容的。Q 是一个坚如磐石的 promise 实现；$q ... 没那么多。
如果有的话，您应该抱怨 $q 不符合规范，正是因为它调用$apply了这种副作用，这种副作用通常是不需要的，尤其是在测试中。不要让我开始。
该fail方法只是 Q 糖，是then. 我们喜欢它的可读性并使用它。
fail如果你愿意，你可以在 $q 承诺中添加一个方法。很简单。类似于别名的东西then(function(data){return data;}, failHandler)
您可以证明我们不应该在fail内部使用 Q 方法，而是将我们在 Breeze 组件中使用 Promise 限制为仅在 CommonJS 规范中标识的那些成员。我会在内部转发这个想法。它肯定会促进 Q 的替代方案的可能性。我个人不喜欢 Breeze 对 3rd 方库有任何依赖，即使是像 Q 这样出色的库。
相信我，我们考虑过这一点。我们无法清除一个障碍：大多数 Promise 实现都是垃圾。
Breeze 依赖于一个 Promise 库，该库在所有条件下都能正常运行，尤其是在处理异常时。如果我们打开这扇门，人们就会开始插入他们想要的任何 Promise 库……任何带有“then”方法的东西。他们的微风应用程序将开始以神秘和不合时宜的方式打破。我们会接到电话告诉我们微风是垃圾。
一个很好的例子：jQuery。jQuery deferred 是一个损坏的实现。如果有人用它代替 Q，Breeze 应用程序就会崩溃。不是所有的时间......这比一直打破更糟糕。
我不会说$q是废话。我会说它是不健全的......不仅仅是因为它总是调用（或相当于调用）$apply。
让我再说一遍我在顶部所说的：请不要EntityManager用 $q 修补微风原型。
我可以想象你为什么要这样做。您希望从EntityManager方法返回的承诺是 $q 承诺。对不起。馊主意。
请改用我的建议。使用我们to$q对 Q.js 的扩展（即将发布的文档）。之后很容易“安装”，而不是这样：
var QPromise1 = someQuery.using(manager).execute(); var QPromise2 = anotherQuery.using(manager).execute().then(success, fail);
你写这个：
var $qPromise1 = someQuery.using(manager).execute().to$q(); var $qPromise2 = anotherQuery.using(manager).execute().to$q(success, fail);
那有多难？
看起来微风响应（使用微风实验室免责声明）是：
“BreezeJS 异步方法返回一个承诺，通常是从远程服务传递一些数据的承诺（如果服务请求失败，则返回一个错误）。
Breeze 方法返回 Q.js 承诺而不是 AngularJS $q 承诺。to$q 插件可以轻松地从 Breeze Q 承诺过渡到 Angular $q 承诺。”