このスタイルガイドの非常に良い情報。 私は、サービスと単一責任、およびこれをどの程度細かくする必要があるかについて質問しました。 たとえば、私はクラッド機能を備えたビデオアプリを持っています。 当初、私のサービス構造は次のとおりです。
// 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アクションが含まれている可能性があるため、ビデオ(getsを使用)とvideo_crud(保存/作成および削除を使用)に分割しないでください。 そうしないと、CRUDサービスの意味が混乱する可能性があります。
それにもかかわらず、それについてのより多くの意見を待ってください:)
一見したところ、最初のサービスはおそらく同じREST APIエンドポイントに対してCRUDを処理し、ビデオ関連の永続性機能を処理します。 $ httpにも同じ依存関係があります。 したがって、分割する理由はありません。その場合、たとえば、メタデータをロードするためにgetVideoを呼び出す必要があるudateVideoメソッドを実装する必要がある場合は、これらの分割サービスが相互に依存することになります。
@viniciusknevesこのアイデアは、パブリックユーザーと管理者ユーザーにアプリを提供するときに実用性を提供します。その時点で、APIサーバーは2つを区別する必要があります。
@tedvanderveen私もそれに同意する傾向があります。 分離の粒度は、モジュールが実行していることよりも、モジュール自体のタイプの方がおそらく存在すると思います。
最初の質問は「なぜ?」です。 それなら.... 'これからどのようなメリットがありますか? `
明らかなメリットはないと思います。 それを明確に定義でき、IFとMAYBEで満たされていない場合を除いて、価値がある可能性があります。
これがガイドに追加されるとは思わないので、問題を閉じますが、質問は適切であり、私は答えたと信じています。
私の見解:それを行うことには十分な価値がありません
@johnpapaご入力いただきありがとうございます。 必要な説明がありました。