Javascript 将$scope传递给服务似乎是个好主意，但是。。？

我发现这种模式非常方便，但我想知道它是否会在以后咬到我：

app.controller('MyController', function($scope, $stateParams, MyPageService){

   var foo = MyPageService.foo($scope);

   scope.bar = function(opts){
      return foo(opts);
   };

   $scope.baz = MyPageService.baz($scope, $stateParams);


});

其中MyPageService看起来像：

app.factory('MyPageService', function(MySharedService){

  return {

      foo: function($scope){
         return function(opts){
             return MySharedService.xyz(opts.v);
          }
      },

      baz: function($scope, $stateParams){
         return function(opts){
             return MySharedService.ijk(opts.z);
          }
      }

  } 

});

这是有角度的，但再一次，这也只是JavaScript，所以这应该是可行的，并且在我对这个模式的简短测试中已经起到了作用

是否有人认为这种模式有什么“错误”之处？未来可能会有什么不可预见的陷阱

---

我必须说，目前这种模式运行得很好。当然，这样做的动机是因为我们的控制器代码变得越来越庞大，并且非常有必要将事情分解成碎片。这似乎是最自然的方法。

这在一个大型应用程序中完全有效，就短期性能而言，没有问题。但是，我还没有检查内存泄漏，但我认为这不会是一个问题。

为什么我们仍然在1.6中使用$scope？将变量绑定到控制器实例。公共逻辑应放在服务中。由于您要将

$scope

传递给服务，这取决于最终使其可重用的作用域。您将重用代码，但对于新的$scope，无论传递给它的$scope是什么。一个新的控制器将向函数传递一个不同的$scope。如果您在服务中丰富scope，没有问题，比如添加一般的crud承诺。但如果继续引用作用域，可能会导致作用域之后的内存泄漏destroy@AlexanderMills“重构旧的1.6项目”。这是最新的1.x分支。但是的，托德的座右铭是一个很好的资源$范围很少在1.3之后使用。