WPFを使用している場合は、MVVMデザインパターンを使用してください。人命をより簡単にし、将来のメンテナンスを容易にします。
コメント
について私たちは、このパターンの使用はのviewmodels 定義時に書き換える必要がありますモデル 定義、中にリワークを引き起こすことができると思います。
MVVMのモデル/ビューモデルを処理する方法は2通りあります。 "MVVM-purist"アプローチは、ViewModelからモデルのプロパティを公開することです。その場合は、コードを複製することになります。より実用的なアプローチは、ViewModelからModel全体を公開することです。 ModelとViewModelレイヤーで作業する別々の人/チームを持つ非常に大きなプロジェクトがない限り、2つ目の方法を使用することをお勧めしますが、どちらの方法も問題ありません。
MVVM純粋主義者:
public class CustomerViewModel
{
private Customer _customer;
public string Name
{
get
{
return _customer.Name;
}
set
{
if (value != _customer.Name)
{
_customer.Name = value;
RaisePropertyChanged("Name");
}
}
}
}
<TextBlock Text="{Binding Name}" />
より実用的なアプローチ:
public class CustomerViewModel
{
private Customer _customer;
public Customer Customer
{
get
{
return _customer;
}
set
{
if (value != _customer)
{
_customer= value;
RaisePropertyChanged("Customer");
}
}
}
}
<TextBlock Text="{Binding Customer.Name}" />
プリズムについては、私はそれは素晴らしいライブラリだと思います。私は彼らのNotificationObject
とEventAggregator
を私のものより好きで、DelegateCommand
のように、CanExecute
のパラメータが変更されたときに、それが自動的にそれを上げないという事実に慣れていればCanExecuteChanged
です。
私が本当に好きではない唯一のものは、RegionManager
です。 ViewModelではなく、Viewコントロールにアプリケーションの流れをあまりにも多くさせているような気がします。私はまた、頻繁にそれがナビゲーションのために誤用されるのを見て、それはかなり混乱に変わる。私はまだ私のアプリケーションレイアウト(例えば、MenuRegion
、NavigationRegion
、ContentRegion
)を定義するためにそれを使用していますが、すべてのナビゲーションニーズに対して私のViewModelを使用しています。
最終的には、私はそれに行くと言うでしょう! WPFでの作業が大好きで、MVVMデザインパターンなしでWPFを使用しないでください。Prismはまた、すべてのMVVMアプリケーションで必要と思われる欠けている機能のいくつかを提供する素晴らしいライブラリです。
これは非常に広範な質問であり、答えは多少意見に基づいているため、StackOverflowの形式には適していません。 MVVMはWPF開発に使用するのに慣れ親しんでおり、Prismは使いやすいDIライブラリであるため、WPFやXAMLに精通すれば生産性が優れています。あなたがあなたの意思決定の保証と妥当性を探しているなら、このような質問をしてはならず、代わりに裁判を行い自分で結果を評価してください。 – slugster
すみません。私はStackOverflowのルールを学んでいます。あなたは私の評判を見て、それを見ることができます。 –
これは大丈夫です。大きな質問をより簡潔な質問に分解するだけでよいのですが、好ましくは決定的な回答があり、「最高のxyz」*または「xyzについて教えてください」などのフレーズを使用しないことが望ましい*彼らは事実ではなく意見を引き出す傾向があるからです。 WPF/MVVM/Prismで遊ぶ必要があり、特定の問題に遭遇したときにここで質問してください。 – slugster