Angular-styleguide: Responsabilité unique des services

Créé le 28 juil. 2015  ·  6Commentaires  ·  Source: johnpapa/angular-styleguide

De très bonnes informations dans ce guide de style. J'avais une question sur les services et la responsabilité unique et à quel point cela doit être granulaire. Par exemple, j'ai une application vidéo avec des capacités brutes. Initialement, ma structure de service est la suivante :


// videos.service.js
(function() {

    'use strict';

    function Videos($http) {
        var service = {
            getVideos: getVideos,
            getVideo: getVideo,
            saveVideo: saveVideo,
            deleteVideo: deleteVideo
        }

        return service;

        function getVideos() {
            // return video list
        }

        function getVideo() {
            // return video by id
        }

        function saveVideo() {
            // add/edit video
        }

        function deleteVideo() {
            // delete video
        }
    }

})();

Serait-il préférable de séparer les fonctionnalités comme celle-ci ?


// videos.service.js
(function() {

    'use strict';

    function Videos($http) {
        var service = {
            getVideos: getVideos,
            getVideo: getVideo
        }

        return service;

        function getVideos() {
            // return video list
        }

        function getVideo() {
            // return video by id
        }
    }

})();

// videos_crud.service.js
(function() {

    'use strict';

    function VideosCrud($http) {
        var service = {
            saveVideo: saveVideo,
            deleteVideo: deleteVideo
        }

        return service;

        function saveVideo() {
            // add/edit video
        }

        function deleteVideo() {
            // delete video
        }
    }

})();

Cela peut dépendre de vos préférences personnelles, mais j'ai pensé que j'aurais un aperçu de quelqu'un à ce sujet.

Merci pour toute suggestion.

question

Tous les 6 commentaires

Je ne suis pas un expert en Angular, mais en tant que service CRUD, il peut inclure toutes les actions CRUD, vous ne devriez donc pas le casser dans les vidéos (avec get) et video_crud (avec enregistrer/créer et supprimer). Sinon, la signification du service CRUD pourrait être confuse.

Néanmoins, attendez plus d'avis à ce sujet :)

À première vue, votre service initial traite CRUD avec probablement le même point de terminaison de l'API REST, gérant votre fonctionnalité de persistance liée à la vidéo. Il a une seule et même dépendance sur $http. Je ne verrais donc aucune raison de diviser les choses, dans ce cas, vous pourriez même vous retrouver avec ces services divisés dépendant les uns des autres au cas où vous auriez besoin d'implémenter une méthode udateVideo qui doit appeler getVideo pour charger des métadonnées, par exemple.

@viniciuskneves Cette idée serait pratique lors de la fourniture d'une application pour les utilisateurs publics et administrateurs, à quel point le serveur API devrait faire la distinction entre les deux.

@tedvanderveen J'ai tendance à être d'accord avec cela aussi. Je suppose que la granularité de séparation existe probablement plus pour le type de module lui-même que pour ce que le module fait.

La première question est « pourquoi ? ». Alors .... « quel avantage en retirerez-vous ? »

Je ne pense pas qu'il y ait un avantage évident. À moins que vous ne puissiez le définir clairement et qu'il ne soit pas rempli de SI et de MAYBE, cela peut avoir de la valeur.

Clôturer le problème car je ne pense pas que cela sera ajouté au guide, mais la question est bonne et je crois y avoir répondu.

Mon point de vue : il n'y a pas assez de valeur à faire cela

@johnpapa Merci pour la contribution. J'ai eu les éclaircissements dont j'avais besoin.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

jusefb picture jusefb  ·  9Commentaires

xavhan picture xavhan  ·  5Commentaires

annabellor picture annabellor  ·  9Commentaires

philmerrell picture philmerrell  ·  10Commentaires

Bekt picture Bekt  ·  13Commentaires