Очень хорошая информация в этом руководстве по стилю. У меня был вопрос об услугах и единой ответственности и о том, насколько это должно быть детально. Например, у меня есть видео-приложение с грубыми возможностями. Изначально моя сервисная структура выглядит следующим образом:
// 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
}
}
})();
Это могло быть связано с личными предпочтениями, но я подумал, что смогу получить хоть какое-то представление об этом.
Спасибо за любые предложения.
Я не эксперт в Angular, но как служба CRUD он может включать все действия CRUD, поэтому вы не должны нарушать его в видеороликах (с помощью get) и video_crud (с сохранением / созданием и удалением). В противном случае смысл службы CRUD может запутаться.
Тем не менее, ждите дополнительных отзывов по этому поводу :)
На первый взгляд, ваша первоначальная служба имеет дело с CRUD для, вероятно, той же конечной точки REST API, обрабатывая ваши функции сохранения, связанные с видео. У него одна и та же зависимость от $ http. Поэтому я не вижу причин для разделения вещей, в этом случае вы можете даже получить эти разделенные службы, зависящие друг от друга, если вам нужно реализовать метод udateVideo, который должен вызвать getVideo, например, для загрузки некоторого метадата.
@viniciuskneves. Эта идея обеспечит практичность при предоставлении приложения для общедоступных и административных пользователей, после чего сервер api должен различать их.
@tedvanderveen Я тоже с этим согласен. Я предполагаю, что степень детализации разделения, вероятно, существует больше для типа самого модуля, чем для того, что модуль делает.
Первый вопрос - «почему?». Тогда ... 'Какую выгоду вы получите от этого?'
Не думаю, что есть очевидная польза. Если вы не можете четко определить это, и оно не заполнено IF и MAYBE, тогда оно может иметь значение.
Закрытие вопроса, так как я не думаю, что это будет добавлено в руководство, но вопрос хороший, и я верю, что ответил.
Моя точка зрения: в этом мало пользы
@johnpapa Спасибо за вклад. Получил необходимые мне разъяснения.