2

BackboneJS を使用しているときに、RESTful のベスト プラクティスに頭を悩ませようとしてきました。私は自分自身を少し結び目に書いたように感じ、いくつかのガイダンスを使用できます.

私のシナリオは次のとおりです。ユーザーは、N 個のアイテムを含む新しいプレイリストを作成したいと考えています。N アイテムのデータは、50 アイテムのバーストでサードパーティ API から取得されます。そのため、新しい空のプレイリストを追加し、50 のバーストが発生したら、アイテムを保存してプレイリストに追加したいと考えています。

これにより、次のような addItems メソッドを持つプレイリスト モデルが作成されます。

addItems: function (videos, callback) {
    var itemsToSave = new PlaylistItems();
    var self = this;

    //  Create a new PlaylistItem with each Video.
    videos.each(function (video) {

        var playlistItem = new PlaylistItem({
            playlistId: self.get('id'),
            video: video
        });

        itemsToSave.push(playlistItem);
    });

    itemsToSave.save({}, {
        success: function () {

            //  OOF TERRIBLE.
            self.fetch({
                success: function () {
                    //  TODO: For some reason when I call self.trigger then allPlaylists triggers fine, but if I go through fetch it doesnt trigger?
                    self.trigger('reset', self);

                    if (callback) {
                        callback();
                    }

                }
            });

        },
        error: function (error) {
            console.error("There was an issue saving" + self.get('title'), error);
        }
    });
}

ItemsToSave は通常、50 個のアイテムを含むコレクションです。BackboneJS はコレクションの保存を提供しないため、独自に作成しました。コレクションのモデル ラッパーを作成することはあまり気にしませんでした。

そのため、Save を呼び出すと、どのアイテムにも ID がありません。データベースは ID を割り当てますが、モデルではなくコレクションを保存しているため、その情報はバックボーンによって暗黙的に更新されません。そのため、保存が成功したら、Playlist で fetch を呼び出して、更新された情報を取得します。プレイリストには何千ものアイテムが含まれる可能性があるため、これはひどいことです。複数のアイテムを保存するたびに何千ものアイテムを取得したくありません。

したがって、コレクションの解析メソッドをオーバーライドし、サーバーの応答をコレクションに手動でマップする必要があるのではないかと考えています。

これはすべて...やり過ぎ/間違っているようです。私はアーキテクチャ的に間違ったことをしていますか? RESTful アーキテクチャは、このようなシナリオをどのように処理しますか?

4

1 に答える 1