Robert Martin は次のように述べています。
View にバインドされている ViewModel クラスを考えてみましょう。ViewModel が実際には相互に関連していないプロパティで構成されている可能性があります (または可能性さえあります)。小さなビューの場合、ViewModel は非常に首尾一貫している可能性がありますが、アプリケーションがより複雑になるにつれて、ViewModel はさまざまな無関係な理由で変更される可能性があるデータを公開します。
ViewModel クラスの場合、SRP の原則について心配する必要がありますか?
1885 次
4 に答える
19
ViewModel の唯一の責任は、必要な情報を View に提供することです。ViewModel を変更する理由は 1 つしかないため、View が別の無関係なプロパティを必要とする場合、それは重要ではありません。それは、別のプロパティを表示する View です。ですから、あまり心配しなくていいのです。
とはいえ、ViewModel が巨大になる場合は、ビューをいくつかのサブビューに分割して、再利用性を向上させ、View と ViewModel を管理しやすくすることを検討できます。
于 2009-02-28T00:44:33.457 に答える
2
私はgcoresに同意します。
ViewModelが2画面以上のテキストに成長するのを確認したら、ViewModelをいくつかの子モデルに分割することを検討します。
もう1つの経験則では、XAMLファイル内に2レベルを超えるネストはありません。ビューの一部が複雑になりすぎた場合は、ビューのリファクタリングを行います。内部XAMLを個別のUserControlに抽出し、対応するViewModelを作成します。子ビューのデフォルトのデータコンテキストになります。
于 2009-02-28T00:50:48.793 に答える
0
肥大化と複雑さを軽減するには、画面を複数のViewModelを持つ複数のビューに分割する必要があることに同意します。MVVMを使用してSRPに固執するために私が採用した別のパターンは次のとおりです。
これが1つのシナリオです。私のViewModelは、データを取得し、UIからフィルターコマンドに応答する必要があります。構造が複合するViewModelを作成します。つまり、ViewModelのプライベートメンバーにアクセスできる子クラスは、フィルタリングの処理などの線形タスクを実行します。また、基準に基づいてアイテムを選択するために必要なロジックを実行する別の子クラスがある場合もあります。あなたはその考えを理解します。ViewModelが複数のメソッドにまたがる特定の関数を実行したら、子クラスに委任することをお勧めします。子クラスはメインのViewModelの一部のままであるため、ViewModelのサイズを縮小する方法にすぎず、これらの線形操作の単体テストが容易になります。
于 2010-03-22T13:47:39.943 に答える
0
はい、しかしそれは、貧弱なデザインがあなたを強制できなかったという意味ではありません.
于 2009-02-27T23:52:06.407 に答える