3

わかりました ここで、熟考する別のポイントがあります。

MVVM は、Model は ViewModel に依存しないと述べています。したがって、ViewModel は、View がバインドするためのプロパティを公開します。

Microsoft コード分析ルールは、モデルのパブリック変数にプロパティを追加するように指示します。

警告 : CA1051 : Microsoft.Design : フィールド 'Employee.name' は宣言型の外側に表示されるため、そのアクセシビリティをプライベートに変更し、現在フィールドと同じアクセシビリティを持つプロパティを追加して、フィールドへのアクセスを提供します。

今では 2 つの繰り返しプロパティがあり、DRY にしたいので、ViewModel と View をマージすることを考えていました。ここには別のことがあります。モデルは POCO であり、INotifyPropertyChanged はありません。そのため、VM にモデル値の変更を知らせることは別の問題です。多くの IList ベースのバインディングを使用しています

私が見落としていた将来の問題はありますか？

編集:言及するのを忘れていましたが、モデルとビューモデルの関係を正しく定義する方法を見ましたか? 、私たちのソフトウェアのもう 1 つのことは、IList に値を設定する別のエンティティ、つまり SERVICE/UTILITY アセンブリがあることです。EmployeeViewModel は別の VIEW アセンブリにあります。したがって、ILIst を返すことはできません。

4

2 に答える 2

2

やらないでください。必要のない余分なものがたくさんあるように聞こえるかもしれませんが、アプリケーションがより複雑になるにつれて、それは報われます。プロパティ通知をサポートし、モデルの表現に結び付けられることなく、ビューが簡単に消費できる方法でデータを表示できるようにバインドする ViewModel を持つことが絶対に不可欠であることがわかりました。ViewModel は、必要に応じて 2 つの間で変換されます。 .

これらのレイヤーがないと、将来、特に特定のレベルの複雑さを超えると、物事を変更することが非常に難しくなります。

モデルでパブリック フィールドの代わりにパブリック プロパティを使用することに関する Microsoft のアドバイスに耳を傾けるかどうかはあなた次第ですが、後で getter と setter に何らかのロジックを入れる必要がある場合は、これを実践することをお勧めします。自動プロパティは、最初は単純なパブリック フィールドの代わりとして適しているため、実際にバッキング フィールドが必要になる前にバッキング フィールドを宣言する必要がなくなります。

于 2013-03-19T08:38:21.573 に答える
0

ここには別のことがあります。モデルはPOCOであり、INotifyPropertyChangedはありません。そのため、VMにモデル値の変更を知らせることは別の問題です

モデルはどこからでも変更できるので (私は想定しています)、他の唯一のオプションは、2 つの INPC を用意することです。1 つは Model-ViewModel 用で、もう 1 つは ViewModel-View 用です。

私は個人的にこのアプローチが好きではありません。フローとリファクタリングの問題が多すぎます (リフレクションを使用しない限り、コードとルックアップが増えますが、保守性が高くなります) 部分クラスを使用してモデルとビューモデルを物理的に分離してみてください。たとえば、Employee.cs と Employee.ViewModel.cs です。それらをグループ化する - 見栄えが良くなる

モデルは移植可能である必要があります。INPC はポータブル クラス ライブラリで問題ないため、さまざまなターゲット間でコードを再利用できます。

于 2013-03-23T04:37:14.267 に答える