Pourquoi utilisons-nous Factories/Services pour les appels ajax dans Angularjs?

Question

On m'a enseigné que nous utilisons des usines/services pour éliminer le codage en double. Voici une partie du code qui fonctionne bien.

app.controller('ServicesCtrl',['$scope','DataFactory',function($scope,$http,DataFactory){ 

    DataFactory.GetData('services1.json') 
     .then(function(response){ 
     $scope.returnedData = response.data; 
    }) 
     .catch(function(response){ 
     console.log('Error in process',response.status,response.data); 
    }); 
    }]); 

app.controller('ContactCtrl',['$scope','DataFactory', function($scope,DataFactory){ 

    DataFactory.GetData('location.json') 
     .then(function(response){ 
     $scope.returnedData = response.data; 
    }) 
     .catch(function(response){ 
     console.log('Error in process',response.status,response.data); 
    }); 
    }]); 

app.factory('DataFactory',['$http',function($http){ 

    var factory = {}; 

    factory.GetData = function(path) { 
    return $http.get(path); 

    } 
    return factory; 
}]); 

Ma question est 1. Pourquoi utiliser les services/usines pour faire de tels appels ajax quand nous devons travailler sur les promesses à l'intérieur des contrôleurs? Je veux dire, je dois faire les mêmes appels .then et .catch dans les deux contrôleurs ici. Où est l'efficacité? Y a-t-il une meilleure façon de faire cela? Ou est-ce que je fais cela mal? Est-il possible de travailler sur ces promesses dans les usines et de renvoyer la réponse aux différents contrôleurs?

Answer 1

La chose ici est la réutilisation du code. Supposons maintenant que vous avez un service appelé

angular.module('test') 
    .service('testService', function ($http) { 

    this.getBidsUser = function ($username) { 
     var endpoint = "bids/users/"+$username; 

     return $http({ 
     method: 'get', 
     url: endpoint 
     }); 
    }; 

} 

qui renvoie les enchères d'un utilisateur. Vous pouvez utiliser les mêmes informations dans différentes vues. C'est donc une bonne idée d'utiliser le service afin de ne pas avoir à réécrire le même code. Une fois de plus, vous voudrez peut-être avoir le même service lié au point d'extrémité sur le même service pour la maintenabilité.

Vous devrez peut-être modifier les points de terminaison pour un service qui sera mouvementé si vous n'utilisez pas le modèle de service.

Promets arr rappels. Si vous traitez ces promesses à l'intérieur d'un service, il ne sera pas facile de gérer la chronologie des appels.

Answer 2

Salut nous utilisons les usines et les services

• pour rendre l'application plus modulaire,
• d'avoir la possibilité de réutiliser le code,
• pour cacher les détails de mise en œuvre

Pour Par exemple, un service qui effectue un appel http peut être vu comme un «service» de haut niveau qui vous renvoie l'objet requis, indépendamment du type d'appel et qui est réutilisable à un niveau élevé.

Le service permet de personnaliser les paramètres d'appel, en évitant éventuellement que certains d'entre eux soient spécifiés par le contrôleur appelant. Ou il peut faire un peu de pré-traitement ou de post-traitement, il peut faire un peu de mise en cache et ainsi de suite. Et son portable, de sorte que vous pouvez l'appeler chaque fois que vous en avez besoin.

Pour votre dernière question

Est-il possible de travailler sur ces promesses à l'intérieur des usines et retourner le response.data à différents contrôleurs?

Peut-être que c'est possible, mais peut être complexe à implémenter comme cela a à voir avec le timing de la réponse. Au lieu de cela, je vous suggère le service de ressources $ dans le module ngResource, qui peut déjà faire ce que vous avez besoin.

Voir docs:

AngularJs Tutorial on $resource

Angularjs Programming guide on $resource