Angular-styleguide: Einzelverantwortung für Dienstleistungen

Erstellt am 28. Juli 2015  ·  6Kommentare  ·  Quelle: johnpapa/angular-styleguide

Sehr gute Informationen in diesem Styleguide. Ich hatte eine Frage zu Dienstleistungen und Einzelverantwortung und wie detailliert dies sein muss. Zum Beispiel habe ich eine Video-App mit Crud-Funktionen. Meine Servicestruktur sieht zunächst wie folgt aus:


// 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
        }
    }

})();

Wäre es besser, die Funktionalität so zu trennen?


// 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
        }
    }

})();

Dies könnte auf persönliche Vorlieben zurückzuführen sein, aber ich dachte, ich würde einen Einblick erhalten, den jemand diesbezüglich haben könnte.

Danke für alle Vorschläge.

question

Alle 6 Kommentare

Ich bin kein Experte für Angular, aber als CRUD-Dienst kann es alle CRUD-Aktionen enthalten, daher sollten Sie es nicht in Videos (mit Gets) und video_crud (mit Speichern/Erstellen und Löschen) aufteilen. Andernfalls könnte die Bedeutung des CRUD-Dienstes verwechselt werden.

Warte trotzdem auf weitere Meinungen dazu :)

Auf den ersten Blick befasst sich Ihr anfänglicher Dienst mit CRUD gegen wahrscheinlich denselben REST-API-Endpunkt, der Ihre videobezogenen Persistenzfunktionen verarbeitet. Es hat ein und dieselbe Abhängigkeit von $http. Ich würde also keinen Grund sehen, die Dinge aufzuteilen. In diesem Fall können Sie sogar mit diesen aufgeteilten Diensten enden, die voneinander abhängig sind, falls Sie beispielsweise eine udateVideo-Methode implementieren müssen, die getVideo aufrufen muss, um Metadaten zu laden.

@viniciuskneves Diese Idee wäre praktisch, wenn eine App für öffentliche vs. Admin-Benutzer bereitgestellt wird, an der der API-Server zwischen den beiden unterscheiden sollte.

@tedvanderveen Dem stimme ich auch zu. Ich vermute, dass die Trennungsgranularität wahrscheinlich eher für den Modultyp selbst gilt als für das, was das Modul tut.

Die erste Frage lautet „Warum?“. Dann .... 'Welchen Nutzen haben Sie davon?`

Ich glaube nicht, dass es einen offensichtlichen Vorteil gibt. Wenn Sie das nicht klar definieren können und es nicht mit IFs und MAYBEs gefüllt ist, kann es einen Wert haben.

Ich schließe das Problem, da ich nicht glaube, dass dies dem Leitfaden hinzugefügt wird, aber die Frage ist gut und ich glaube beantwortet.

Meine Perspektive: Das hat nicht genug Wert

@johnpapa Danke für den Input. Habe die nötige Aufklärung bekommen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

annabellor picture annabellor  ·  9Kommentare

andreshg112 picture andreshg112  ·  3Kommentare

jejja picture jejja  ·  25Kommentare

philmerrell picture philmerrell  ·  10Kommentare

nonopolarity picture nonopolarity  ·  5Kommentare