MVVM/ViewModel/UserControl/DataContext/Command - デザインの問題/ディスカッション

エンティティ（従業員、ビジネスなど）の1つ以上のアドレスを表示/管理するユーザーコントロールがあります。MVVM/ViewModel/UserControl/DataContext/Command - デザインの問題/ディスカッション

私は、コントロール内のアドレスのUIをカプセル化することで、さまざまなビューからこのユーザーコントロールを活用しました。

私は保持するいくつかのviewmodelsを持って/さまざまな異なる視点からのアドレス収集公開 - これは、それぞれ通常、私は、ユーザーに適切なのDataContextに合格した

異なるViewModelに（各ビューの1 ViewModelに）によって管理されているがつまり、私はAddress Collectionを公開する様々なViewModelを持っていますが、私はDCバインディングを介して適切なコンテキストを渡すことができます。

私の質問は、どこにコマンドロジックを追加してアドレスを削除するのですか？私は単純にコードを繰り返すので、各ビューモデルで同じコマンドを置くことは望ましくありません。

MVVMを初めて使用しているので、IAddressCommandインターフェイスでクラスを作成してから、各ViewModelのコマンドをスタブアウトするだけですか？ビューモデルを別のViewModelにカプセル化するだけですか？

思考？

よろしくリチャード

出典

2011-01-06 codeputer

コマンドは、アドレスの種類ごとに同じ場合は、[アドレスのviewmodelsが継承するベースのViewModelを持つことを検討してください。共通コマンドコードは、基本クラスに置くことができます。

出典

2011-01-06 17:58:57

いいですが、すでにすべてのViewModelの基本クラスがあり、複数の継承が機能しません。 – codeputer

@codputer既存の 'ViewModelBase'から継承したAddressViewModelを導入し、既存のクラスを継承するように変更することができます。 –

これは機能しますが、コンポーネントのDataContextの問題は、ViewModelから直接設定されたコマンドメンバとは異なるオブジェクトグラフのレベルで設定されます。 DataContextをオブジェクトグラフの上に移動すると、フィールドバインディングはツリーのさらに深いレベルを参照する必要があります。 – codeputer

ViewModels：Viewに関して1：1のアプローチが必要な場合は、これらのコンポーネントを結合するサービス（ViewModelではない）を提供します。次に、ViewModel内のサービスを呼び出して、基になるコレクションからアドレスを追加/削除します。このサービスは、必要に応じて複数のViewModelで使用できます。

デザインを調整したい場合は、単一のViewModelを使用するか、元のコレクションからアドレスを追加/削除する機能を提供し、複数のビューで消費され使用される可能性があります。

IMHOが最初のルートを実行し、このワークロードをサービスに抽象化する方が良い方法です。どちらでも十分です。

出典

2011-01-06 18:01:27

コマンドボタンをサービスにバインドすることをどのように提案しますか？ DCはバインディングのコンテキストを設定し、コマンドボタンはフィールドバインディングよりオブジェクトグラフの方が高くなります。 FirestartedのScottGuは、Silverlight 5では、DCツリーをバインドするコマンドを検索するAncestor（？）バインディング句があると述べています。 – codeputer

@codputer現在のようにコマンドをViewModelにバインドしますが、サービスを呼び出すコマンドのアクションポイントにバインドします。サービス自体にバインドしようとしないでください。 –

MVVM/ViewModel/UserControl/DataContext/Command - デザインの問題/ディスカッション

答えて

関連する問題