Angular-styleguide: Single Responsibility of Services

Created on 28 Jul 2015 · 6Comments · Source: johnpapa/angular-styleguide

Very good information in this style guide. I did have a question on services and single responsibility and how granular this needs to be. For instance, I have video app with crud capabilities. Initially my service structure is as follows:


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

})();

Would it be better to separate out the functionality like this?


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

})();

This might come down to personal preference but thought I would get any insight someone might have regarding this.

Thanks for any suggestions.

question

Source

robrothedev

All 6 comments

I'm not an expert in Angular but as a CRUD service it might include all CRUD actions so you shouldn't break it in videos (with gets) and video_crud (with save/create and delete). Otherwise the meaning of CRUD service might get confused.

Nevertheless, wait for more opinions about it :)

viniciuskneves on 28 Jul 2015

At first sight your initial service deals with CRUD against probably the same REST API endpoint, handling your Video related persistence functionality. It has one and the same depenency on $http. So I would see no reason to split things up, in that case you may even end up with these split services depending on each other in case you need to implement an udateVideo method that needs need to call getVideo to load some metadat, for example.

tedvanderveen on 28 Jul 2015

@viniciuskneves That idea would provide practicality when providing an app for public vs. admin users at which point the api server should be discerning between the two.

@tedvanderveen I tend to agree with that also. I guess the separation granularity probably exists more for the type of module itself rather than what the module is doing.

robrothedev on 28 Jul 2015

The first question is 'why?'. Then .... 'what benefit will you get from this?`

I don't think there is ay obvious benefit. Unless you can define that clearly and it is not filled with IFs and MAYBEs, then it may have value.