64

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

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

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

4

4 に答える 4

127

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

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

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

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

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

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

編集：

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

1-非MVVMWPF：

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}。

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

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

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

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

于 2013-01-17T15:13:37.243 に答える
15

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

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

正しく行われた場合、MVVMはあなたが読んだあらゆる種類の利点を提供します。逆に、それが間違って行われた場合、それは開発と保守の悪夢になる可能性があります-間違いなく、より読みやすく、使いやすいものではありません。個人的な経験から、MVVMベースのアプリではなく、コードビハインドアプリの方が簡単だと思います。

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

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

確かに、彼らはできます。EFはデータアクセステクノロジーであり、MVVMはデザインパターンであることを忘れないでください。あなたが言及するDALクラスでおそらくEFを使用するでしょう。

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

于 2013-01-17T15:18:10.913 に答える
2

Unityのようなフレームワークを使用して、DependencyInjectionを確実に調べます。

シングルトンクラスは、DependencyInjectionコンテナーに登録して、他のクラス（ViewModelsなど）のコンストラクターに注入することができます。したがって、定期的にインスタンス化してクラスに挿入する必要がある他のDALクラスも可能です。

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

于 2013-11-14T13:24:49.583 に答える
2

これらはMVVMに固有の鉱山です

1）ビューの「ブレンド可能性」（Expression Blendを使用してビューをデザインする機能）を向上させます。これにより、幸運にもデザイナーとプログラマーがいるチームの責任を分離することができます...それぞれが互いに独立して作業できます。

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

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

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

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

実際、私の意見では、MVP（監視コントローラーではなく、パッシブビュー付き）は実際にはMVVMの単なる変形です。

于 2015-03-05T07:20:11.353 に答える