web-dev-qa-db-ja.com

WPFプログラミング方法論

私のアプリでは、ツールが管理しているソフトウェアのAPIを使用しています。私は16個のクラスを含むDALを使用していますが、そのうちの3つはシングルトンです。 .csファイルにいくつかのロジックがあり、XAMLはオフコースです。

私の質問は、WPFで記述されたアプリはMVVMを使用する必要があるというコメントがたくさんあることです。これにより、コードがより使いやすく、読みやすくなります。コードをMVVMに変換できますか？それはMVVMの実際の意味です（ウィキペディアや手動の定義ではありません）？

SQLクエリも使用していて、EF（Entity Framework）に関する論文を読んでいますが、MVVMとEFは同じプロジェクトで共存できますか？

wpfentity-frameworkmvvm.net-4.5
63
SigmaOmega

MVVMの実際の意味は次のとおりです：UIはデータではありません。データはデータ、UIはUIです。

つまり、プログラムロジック（ビジネスロジックと呼ばれることが多い）がUIコンポーネントの状態に密接に結合または依存するようにアプリケーションを開発するのではなく、データ項目（モデルであっても）の状態に依存させる必要があります。 、またはビューモデル）。

たとえば、他のフレームワーク（winformsなど）では、テキストボックスとボタンを含む画面がある場合、通常、ボタンにクリックイベントハンドラーを追加して、テキストボックスからテキストを読み取ります。 MVVMでは、TextBoxのTextプロパティをViewModelの文字列プロパティにバインドし、ボタンをViewModelのコマンドにもバインドする必要があります。

これにより、UI（ViewModel）の抽象化が可能になるため、前に述べたように、アプリケーションロジックはUIではなくその抽象化に依存できます。

これにより、UIとロジックのスケーラビリティが大幅に向上し、UIの動作の大部分がViewModelで定義されているため、UIの動作のいくつかの側面をテストできるようになります。

MVVMには他の側面もありますが、主な実現はそれです。

編集：

答えを完全にするために、この具体例を追加します。

1-非MVVM WPF：

XAML：

<StackPanel>
   <TextBox x:Name="txtLastName"/>
   <Button Content="Click Me" Click="Button_Click"/>
</StackPanel>

コードビハインド：

private void Button_Click(object sender, EventArgs e)
{
    //Assuming this is the code behind the window that contains the above XAML.
    var lastname = this.txtLastName.Text; 

    //Here you do some actions with the data obtained from the textbox
}

2-MVVM WPF：

XAML：

<StackPanel>
   <StackPanel.DataContext>
       <my:MyViewModel/>
   </StackPanel.DataContext>
   <TextBox Text="{Binding LastName}"/>
   <Button Content="Click Me" Command="{Binding MyCommand}"/>
</StackPanel>

ViewModel：

public class MyViewModel
{
    public string LastName { get; set; }

    public Command MyCommand { get; set; }

    public MyViewModel()
    {
        // The command receives an action on the constructor,
        // which is the action to execute when the command is invoked.
        MyCommand = new Command(ExecuteMyCommand); 
    }

    private void ExecuteMyCommand()
    {
        //Only for illustration purposes, not really needed.
        var lastname = this.LastName; 

        //Here you do some actions with the data obtained from the textbox
    }
}

上記の例でわかるように、ViewModelにはビューへの参照がまったく含まれていません。したがって、{Bindings}が適切に保持されている限り、ビューは何でもかまいません。

それらを魔法のように連携させる接着剤は、WPF UI要素のDataContextプロパティです。これは、すべてのバインディングが解決されるオブジェクトです。

他に、双方向バインディングを有効にするためのViewModelのプロパティ変更通知などがありますが、これはこの回答の範囲外です。

また、WVMはフレームワークであるのに対して、MVVMは設計パターンであることにも留意してください。 MVVMは現在、他のテクノロジーにも適用されています（現在、JavaScriptなどのWeb向けのMVVMについて多くの話題があります）。

WPF固有の側面については、他の回答で言及されている本と このチュートリアル を読むことをお勧めします。

119
Federico Berasategui

私の質問は、WPFで記述されたアプリはMVVMを使用する必要があるというコメントがたくさんあることです。これにより、コードがより使いやすく、読みやすくなります。コードをMVVMに変換できますか？

MVVMパターンを使用する必要はありません-なし。作成するアプリの複雑さと開発グループのスキルセットを考慮する必要があります。一般的に言えば、それが小規模または小規模/中規模のアプリである場合、MVVM mayは過剰なエンジニアリングになります。グループのスキル/才能が個別のプレゼンテーションパターンに適していない場合、MVVMは適切な決定ではない可能性があります。

正しく行うと、MVVMは、これまでに読んだあらゆる種類の利点を提供します。逆に、それが間違っていると、開発と保守の悪夢になる可能性があります。個人的な経験から、私はMVVMベースのアプリよりも、貧弱に書かれた分離コードアプリで作業する方が簡単だと思います。

もちろん、現在のアプリをMVVMパターンに書き換えることができます。分離コードを削除して、ビューモデル、ヘルパークラス、リポジトリクラス、ビジネスロジッククラスなどに配置するだけです。ビューモデルにすべてを入れてMVVM美化コードを作成するという罠に陥らないでください。 -後ろに。

SQLクエリも使用していて、EF（Entity Framework）に関する論文を読んでいますが、MVVMとEFを同じプロジェクトにまとめることはできますか？

もちろん可能です。 EFはデータアクセステクノロジであり、MVVMは設計パターンであることを覚えておいてください。あなたはおそらくあなたが言及するあなたのDALクラスでEFを使うでしょう。

最後に、MVVMルートを使用する場合は、Prismなど、それを容易にするフレームワークの使用を検討する必要があります。ああ、そしてかなりの学習と欲求不満の準備をしてください。

15
Big Daddy

私は間違いなく nity のようなフレームワークを使用して、 DependencyInjection を調べます。

シングルトンクラスをDependencyInjectionコンテナーに登録し、他のクラス（ViewModelなど）のコンストラクターに注入できます。したがって、定期的にインスタンス化してクラスに注入する必要がある他のDALクラスも考えられます。

DependencyInjectionは、大規模なエンタープライズソフトウェアアプリケーションを開発するときに最も重要な単一の設計パターンであり、クライアントコードとサーバーコードの両方に適用できます。 MVVMは素晴らしいパターンですが、依存関係の結合に関連するアプリケーション全体の複雑さの問題には対処しません。

2
Dr. ABT

これらはMVVMに固有のものです

1）ビューの"Blendability"を増やします（Expression Blendを使用してビューを設計する機能）。これにより、幸運なことに、デザイナーとプログラマーがいるチームの責任を分離することができます。それぞれが互いに独立して作業できます。

2）"Lookless"ロジックを表示します。ビューは、背後で実行されるコードに依存しないため、同じビューロジックを複数のビューで再利用したり、ビューを簡単に再構築または置換したりできます。 「行動」と「スタイル」の間の懸念を分離します。

3）ビューを更新するための重複するコードはありません。コードビハインドでは、 "myLabel.Text = newValue"への呼び出しが随所に散らばっています。 MVVMを使用すると、基になるプロパティとそのすべてのビューの副作用を設定するだけで、ビューが適切に更新されます。

4）Testability。ロジックはビューに完全に依存しないため（ "myLabel.Text"の参照はありません）、単体テストが簡単になります。ビューに関係なく、ViewModelの動作をテストできます。これにより、コードビハインドを使用してほぼ不可能であるビュー動作のテスト駆動開発も可能になりました。

他の2つのパターンは、それらが対処する懸念の点で、実際には別個のものです。 MVVMをMVPおよびMVCと一緒に使用できます（市販されているほとんどの優れたサンプルが何らかの形でこれを実行しています）。

実際、私の意見では、MVP（監視コントローラーではなく、パッシブビューを使用）は、実際にはMVVMの変形にすぎません。

2
Dhru 'soni