Angular-styleguide: Единая ответственность за услуги

Созданный на 28 июл. 2015  ·  6Комментарии  ·  Источник: johnpapa/angular-styleguide

Очень хорошая информация в этом руководстве по стилю. У меня был вопрос об услугах и единой ответственности и о том, насколько это должно быть детально. Например, у меня есть видео-приложение с грубыми возможностями. Изначально моя сервисная структура выглядит следующим образом:


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

})();

Не лучше ли выделить такую ​​функциональность?


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

})();

Это могло быть связано с личными предпочтениями, но я подумал, что смогу получить хоть какое-то представление об этом.

Спасибо за любые предложения.

question

Все 6 Комментарий

Я не эксперт в Angular, но как служба CRUD он может включать все действия CRUD, поэтому вы не должны нарушать его в видеороликах (с помощью get) и video_crud (с сохранением / созданием и удалением). В противном случае смысл службы CRUD может запутаться.

Тем не менее, ждите дополнительных отзывов по этому поводу :)

На первый взгляд, ваша первоначальная служба имеет дело с CRUD для, вероятно, той же конечной точки REST API, обрабатывая ваши функции сохранения, связанные с видео. У него одна и та же зависимость от $ http. Поэтому я не вижу причин для разделения вещей, в этом случае вы можете даже получить эти разделенные службы, зависящие друг от друга, если вам нужно реализовать метод udateVideo, который должен вызвать getVideo, например, для загрузки некоторого метадата.

@viniciuskneves. Эта идея обеспечит практичность при предоставлении приложения для общедоступных и административных пользователей, после чего сервер api должен различать их.

@tedvanderveen Я тоже с этим согласен. Я предполагаю, что степень детализации разделения, вероятно, существует больше для типа самого модуля, чем для того, что модуль делает.

Первый вопрос - «почему?». Тогда ... 'Какую выгоду вы получите от этого?'

Не думаю, что есть очевидная польза. Если вы не можете четко определить это, и оно не заполнено IF и MAYBE, тогда оно может иметь значение.

Закрытие вопроса, так как я не думаю, что это будет добавлено в руководство, но вопрос хороший, и я верю, что ответил.

Моя точка зрения: в этом мало пользы

@johnpapa Спасибо за вклад. Получил необходимые мне разъяснения.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги