从我的理解$ http请求是低级别，但非常灵活和可配置，而处理RESTful API ngResource对象使交流非常简单。
我想我所询问的是一个非常简单的场景，说从服务器(对象数组的GET请求)检索数据是更有效的简单地使用$ http请求，而不是包装在服务(应该是这样的情况吗？)或使用ngResource对象？
任何想法在这里将不胜感激。例如，一个$ http响应可以被缓存，一个ngResource？谢谢。
使用$ http或$ resource，结果仍然可以缓存，你指出了在你的问题中真正使用一个的原因。如果你有一个RESTful接口，那么使用$ resource是更好的，因为你最终会写一个RESTful接口常见的样板代码，如果你不使用RESTful服务，那么$ http更有意义。您可以通过http://www.pseudobry.com/power-up-http-with-caching/缓存数据
我认为将$ http或$资源请求放入服务通常工作更好，因为您想要访问来自多个位置的数据，该服务作为单身。所以，基本上你可以处理任何类型的缓存，你想要做的，控制器都可以只看到相应的服务来更新自己的数据。我发现一个$ watch在控制器中的数据服务和返回promise从我的服务的方法的组合给我最大的灵活性，如何更新控制器中的东西。
我会把这样的东西在我的控制器中，在控制器定义的顶部注入exampleService。
angular.module("exampleApp",[]).service('exampleService',["$http","$q",function ($http,$q) {
var service = {
returnedData: [],dataLoaded:{},getData = function(forceRefresh)
{
var deferred = $q.defer();
if(!service.dataLoaded.genericData || forceRefresh)
{
$http.get("PHP/getSomeData.PHP").success(function(data){
//service.returnedData = data;
//As Mark mentions in the comments below the line above could be replaced by
angular.copy(data,service.returnedData);
//if the intention of the watch is just to update the data
//in which case the watch is unnecessary and data can
//be passed directly from the service to the controller
service.dataLoaded.genericData = true;
deferred.resolve(service.returnedData);
});
}
else
{
deferred.resolve(service.returnedData);
}
return deferred.promise;
},addSomeData:function(someDataToAdd)
{
$http.post("PHP/addSomeData.PHP",someDataToAdd).success(function(data){
service.getData(true);
});
}
};
service.getData();
return service;
}]).controller("ExampleCtrl",["$scope","exampleService",function($scope,exampleService){
//$scope.$watch(function() {return exampleService.returnedData},function(returnedData){
// $scope.myModel.someData = returnedData;
//});
//if not using angular.copy() in service just use watch above
$scope.myModel.someData = exampleService.returnedData;
}]);
这里还有一个来自Angular团队的最佳实践的视频，我仍然在重新观看，慢慢吸收。
http://www.youtube.com/watch?v=ZhfUv0spHCY
特别关于服务vs控制器：
http://www.youtube.com/watch?v=ZhfUv0spHCY&t=26m41s
