私たちのアプリケーションには、何百ものプロパティを持つ多くのModelオブジェクトがあります。
モデルのすべてのプロパティについて:
public string SubscriptionKind { get; set; }
...100x...
ViewModelで INotifyPropertyChanged 対応のプロパティを作成する必要がありました。
#region ViewModelProperty: SubscriptionKind
private int _subscriptionKind;
public int SubscriptionKind
{
get
{
return _subscriptionKind;
}
set
{
_subscriptionKind = value;
OnPropertyChanged("SubscriptionKind");
}
}
#endregion
...100x...
これは、ビューがSaveイベントを送信したときに、ビュー モデルのこれらすべての値をモデルに再マッピングする必要があることを意味します。
customer.SubscriptionKind = this.SubscriptionKind
...100x...
モデルが変更され続け、すべての変更を ViewModel にマッピングする必要があったため、これは面倒で時間がかかりました。
しばらくして、View の DataContext をModel に直接接続する方が簡単であることに気付きました。これにより、XAML 要素を Model オブジェクトのプロパティに直接バインドできるようになり、save イベントでオブジェクトが何も指定されずに単純に保存されるようになります。マッピングは何でも。
この移動で失ったものは次のとおりです。
UpdateSourceTrigger=PropertyChanged
ViewModel プロパティ セッターできめ細かな検証と操作を行う機能。これは非常に気に入りました。これは、XAML を変更するとモデルのダム プロパティが単純に変更されるため、もうありません。ビューモデルの UI ロジックを斬新な方法でテストするモック ビューを(将来的に) 作成する機能。 」、および(3)注文ボタンをより目立つようにします。
これらのアプローチにはどちらも明らかな利点があります。たとえば、最初の方法である「View-direct-to-Model」アプローチは、特にLINQ-to-SQLと組み合わせると実用的であり、有用なソフトウェアを迅速に作成できます{Binding...}
。x:Name
「ビューを Blend Designer に渡す」機能はまだあります。
一方、MVVM では Model から ViewModel への面倒なマッピングを維持する必要がありますが、最初のアプローチにはない強力な検証とテストの利点が得られます。
プロジェクトでこれら 2 つのアプローチの利点をどのように組み合わせることができましたか?