2012-08-30 11 views
12

他の人と同じ情報を必要とする意見があることに気付きました。しかし、時には、あなたはビューモデルの5つの性質を必要とし、時には唯一の2異なるビューでビューモデルを再利用する必要がありますか?

はあなたに多くのビューを超えるシェアなビューモデルを実行したり、各ビューのために別々ビューモデルを作成するか、または多分あなたはをprefereありません継承または構成の戦略ですか?私にとって

ビューモデルを共有するためのいくつかの欠点があります:最小サプライズの

  1. 原則:あなたはドンので、ビューモデルの5の2つのみのプロパティを記入し、null参照の例外を取得する奇妙ですが、」データベースの追加データを照会する必要はありません。ビューモデルに5つのプロパティがある場合は、すべてが満たされると予想します。例外はルールを証明します。
  2. 懸念の分離/単一責任原則:複雑なサイトではビューモデルが複雑になります。ビューごとに異なるニーズに対応する必要があるためです。ロジックが複雑になっている場合は、それも複雑です。

あなたはどう思いますか?どのようにこのような状況に対処していますか?

答えて

7

私が取り組んでいるプロジェクトでは、各ビューに独自のViewModelがありますが、複数のビューモデルで共有/参照されるCollectionViewModelsもあります。

Think - アプリケーションの複数の画面に表示する必要があり、さまざまなコントロール(リストボックス、グリッドビュー、必要なもの)にバインドされているサプライヤのリスト。 ViewModelが1つだけであれば、サプライヤのリストの更新/リフレッシュロジックが簡単になります。

TLDR:すべての使用例でViewModelを同じ方法で使用する場合は、ビューモデルのみを再利用します。私。それらはすべて同じプロパティなどを使用します。

4

私はビューごとに別々のViewModelを持っています。未使用のプロパティは、コードを読みにくくします(使用されていない場合、そのプロパティはなぜ存在しますか?)。いくつかのビューにわたって固定されたプロパティのセットに対して同じ機能を持っている場合、それらのプロパティを含む基本クラスを使用して見ることができます。

2

私は通常、ViewModelsを共有します。私が理解しているように、ビューモデルを使用する利点は、(a)隠されるべきプロパティがセキュリティであり、(b)ビジネスレイヤとプレゼンテーションレイヤ間の懸念が分離されるというセキュリティです。 (b)は、ビューモデルを共有しながら全く同じように実行されます。

(a)については、プロパティを公開することはセキュリティリスクであるが、ある場所では公開することはめったにありません。プロパティを非表示にする必要がある場合は、おそらくどこにでも隠す必要があります。もちろん、YMMVですが、これはかなり主観的な質問のようです。

0

私はエンティティフレームワークをコードファーストで使用していますので、ドメインクラスはSQLデータベースにマッピングされるため、かなり厳格にする必要があります。

一部のビューでは、直接マッピングされたエンティティが1つだけ使用されますが、それは素晴らしいので、同じドメインレイヤエンティティを使用します。そのエンティティがより多くの情報(たとえば2つのパスワードフィールド)を必要とする場合、私は構成を使用します。 'Compositionは継承よりも優先されるべきです'ということは、あなたが作曲を使うことができれば、通常はそれが単なる追加の性質であるので、作曲を使うことができるということです。

セキュリティエンティティの2つのプロパティのみを使用する画面がある場合、またはセキュリティ上の理由でプロパティを非表示にする場合は、新しいビューモデルを作成し、必要なデータのみを取得します。他のビューで同じプロパティが必要な場合にのみ、ビューモデルを再利用します。

8

ViewModelsの考え方に基づいて人々は異なる考え方を持っている傾向があります。 ViewModelsはビューとモデルの間の接着剤であり、人々は通常、より固いものを保持するのが好きな2つの端のどちらに基づいて答えを導きます。

  • あなたはより剛性であるためにあなたのモデル/データオブジェクトを好きなら、あなたが複数のビューで使用される単一のViewModelを持っています。すなわち、あなたは近いモデル/データ—へのViewModelを結びつける傾向がありますし、 ViewModelはデータのロードをどのように処理するか(画像やその他の長時間ロードするプロパティなどの処理を延期する方法)に基づいて、取得するプロパティを決定します。
  • ビューをもっと剛性にしたい場合は、ビュー—に近いViewModelを結び付けます。つまり、ビューごとに別々のViewModelを用意し、モデル/データオブジェクトで視点からビュー。

私のデータは、それがビューがあるよりも、変更する可能性が低いですので、より剛性である傾向があるようプロジェクト—に私はそれがデータとビューの普遍的な性質はないと思う(個人的に、私は最初のを好みます)。変更通知はViewModelsの自然な機能なので、ユーザーが同じ/類似のデータを表示する2つのビューを持っている場合、モデルオブジェクトに変更を通知する必要はありません。

2

ビューごとに1つのViewModel、imho。

アプリケーションが複雑になるにつれ、共有ViewModelは成長する傾向があり、必要なすべてのプロパティが1つのプロパティであれば、50個のプロパティを持つオブジェクトをViewに渡すことは気になりません。

また、ViewModelに、ビューに完全に固有のプロパティを追加し、他のビューでは不要なプロパティを追加することもできます。 ViewModelのプロパティに依存するCSSクラスがあるとします。ビューにelse文を書くのではなく、ViewModelにプロパティを作成して、持つビジネスルールに基づいて正しいcssクラスを返します。このようにしてViewを可能な限り細くし、専用のViewModelを使ってCSSクラス名を実際に気にしないViewと共有しないでください。

0

すべてのプロパティ変数とメソッドがすべてのビューで使用されている場合のみ、複数のビュー間でVMを共有します。そうでなければ、継承と抽象的なベースビューモデルを使用します。 1対1で

関連する問題