1

Breeze を介して取得されたエンティティの observableArray を持つビュー モデルがあります。

// define the viewmodel
function episodesViewModel() {

this.episodes = ko.observableArray();
...
}

各エピソード エンティティには一連のプロパティがあり、ページの読み込み時にすべて入力する必要があります。次に、サーバーからの取得時およびサーバーへの保存時に、これらのプロパティの 1 つだけを更新するにはどうすればよいですか? 他のプロパティははるかに大きく、静的なままであるため、ワイヤを介してそれらをやり取りしても意味がありません。

4

2 に答える 2

1

または、帯域外AJAX呼び出しを使用して従来のルートに進むこともできます。

HTTPPATCHに応答する独自のWebAPIコントローラーアクションメソッドを追加します。あなたはそれを正しいことをさせます。

変更されたデータを使用して、クライアントから（jQuery AJAXまたは増幅.jsを使用して）呼び出しEpisodeます。これは、単純なWebAPI/AJAXプログラミングです。

ユーザーがエンティティに直接変更を加えた場合は、Episode帯域外保存で何が起こるかに応じてエンティティを調整する必要があります。EntityManager.getChanges('Episode')キャッシュから変更されたEpisodeエンティティを提供します。保存が正常に完了したら、コールバックで呼び出して、が変更された状態ではなくなったことをepisode.entityAspect.acceptChangesBreezeに通知できます。EntityManagerepisode

于 2013-02-24T21:32:14.910 に答える
0

素晴らしい質問です！

あなたへの最初の質問は、「追加の「静的プロパティ」のペイロードの重みが実際に問題であると確信していますか?」です。私はあなたに尋ねなければなりません...私は自分自身に尋ねなければならないので...私は問題を予測して時​​期尚早に解決する傾向があるからです. 測定後、その作業と心配は、現場でのアプリケーションにとってはまったく問題にならないことがわかりました。私の無礼をお許しください。

あなたが本当に問題を抱えていると仮定しましょう。オブジェクトが非常に重く (おそらく画像データを使用)、モデル内でそれらを 1 対 1 の関係を持つ複数のクラスに分割episodeすることはできません。あなたは 1 つの大きな太ったクラスで立ち往生しています。私はこれが起こることを知っています。チェックしてるだけ。EpisodeEpisodeDetailEpsiode

あなたはあなたが望むことをすることができます。Breeze では、このシナリオをより簡単にしたいと考えています。今日、それを行うための「OK」な方法があります (ハックと呼ぶ人もいます)。その概要をここにレイアウトします。あなたはそれを試すことができます...そしてそれを改良する方法を私たちに知らせてください.

  1. 保存するオブジェクトEpisodeSaveDtoの形状を表すDTO クラス ( ?) をサーバー上に作成します。保存する と プロパティが必要ですEpisode。Id

  2. これは実際のエンティティではないため、サーバーから送信される通常のメタデータの一部にはなりません。そのため、BreezeJS クライアントの JavaScript のメタデータにその DTO オブジェクトを記述します。その後、Breeze はあなたEpisodeSaveDtoをエンティティとして扱います。この手法の例については、 「NoDb」サンプルを参照してください。

  3. のインスタンスを作成EpisodeSaveDtoし、変更を加えます。新しいインスタンスを追加するのではなく、更新しているので、メソッドで EntityState 設定シグネチャをcreateEntity使用します。

    var episode = manager.createEntity("EpisodeDto",
   { id: origEpisode.id,
     foo: 変更されたFooValue },
   EntityState.Modified);

  4. サーバーのカスタム (派生)EFContextProviderで、メソッドをオーバーライドしますBeforeSaveEntities。このメソッドは、変更されたエンティティのディクショナリをタイプ別に並べて受け取ります。

  5. 変更のコレクションを削除し、EpisodeSaveDtoそれらを適切なEpisodeエンティティに処理して保存します。EF または SQL Db を使用していない場合は、 "NoDb" SampleContextProviderに示されているように、...の実装でこれを行うことになります。

  6. すぐに保存できるEpisodeエンティティのコレクションを変更されたエンティティのディクショナリに追加し、それらを EF コンテキストにもアタッチします。

サーバー上の Breeze.NET は、製造さEpisodeれたエンティティをサーバーに保存し、着信を無視しますEpisodeSaveDto(保存方法がわからないため)。

自白：私はこれを記憶から書いていますが、ステップ＃6で少し曖昧です. 私はあなたがアイデアを得ると信じています。Breeze.NET をごまかしています。

最初に言ったように、このシナリオをもっと簡単にしたいと思います。エンティティ セットを受け入れて返すことができる "コマンド" のサポートが組み込まれていることを期待しています。これが私たちがすべきことだと思う場合は、Breeze User Voiceに投票してください。

于 2013-02-24T21:23:40.010 に答える