4

私は WPF の初心者で、今朝、C、C++ のバックグラウンドを持つアーキテクトと話し合っています。

を作成して、ネイティブ dll に依存するビデオ通話アプリケーションを作成しようとしていますPInvoke。WPF アプリケーションは主に UI であり、コード ビハインドではPinvoke、ビデオ/オーディオの呼び出しを行い、利用可能なドライバーを一覧表示しています。

したがって、データをデータベースからのものとして話している場合、アプリケーションに含まれる「データ」はあまりありません。

変更しようとしている WPF アプリケーションはBogheであり、驚くべきことに、それらも MVVM を使用していません。

私はMVVMの実装に熱心ですが、アーキテクトはファイルを不必要に3つの部分に分割していると指摘しています。

ボタンやコントロールの変更など、ビュー内の何かを変更したい場合は、コード ビハインドで直接行うことができると彼は言います。なぜMVVMを使用するのですか？

私は理論的な答えを持っていますが、彼の主張に同意せずにはいられません。彼は実際に正しいですか？

4

5 に答える 5

6

ボタンやコントロールの変更など、ビュー内の何かを変更したい場合は、コード ビハインドで直接行うことができると彼は言います。なぜMVVMを使用するのですか？

もちろん、この方法で行うこともできます。問題は、このようにすべきかどうかです。

かなり小さなコード ベースの場合、コード ビハインドでデータ アクセス、コア ロジック、および UI 操作を混同しても問題を解決できる可能性があります。しかし、長い目で見れば、それでは保守やテストが可能なコードにはなりません。混乱は時間の経過とともに悪化し、スパゲッティ コードに変わる可能性があります。仕事での私の時間のかなりの部分は、そのような古い混乱を元に戻すことに費やされているので、私の言葉を信じてください.

コード ビハインドですべてを混同すると、次のような結果が生じます。

  • 「Single Responsibility Principle」（SRP）に根本的に違反するコード。
  • 非常に異なることをすべて同じ場所で行うため、理解しにくいコード。
  • 簡単に壊れるコード。ここで何かを変更すると、なんらかの難解な理由で、いくつかの機能が機能しなくなります。
  • コードの重複/「Don't Repeat Yourself」(DRY) 原則の違反。多くの場合、複数の場所で同じロジックが見つかります。これは偶然ですか、それとも故意ですか？ここでロジックを変更すると、あちらの同じ/類似のロジックも変更する必要がありますか?

最初の点を除いて、これらは理論的な懸念事項ではなく、典型的な「レガシー」コード ベースの非常に現実的で差し迫った問題であることに注意してください。

私の意見では、MVVM がより多くのコード ビハインドクラスを導入するというのは完全に正しいとは言えません。これは明らかに、データ、ビジネス ロジック、および UI論理レイヤーを互いに分離することで得られる懸念事項の根本的な分離を高く評価していない人の発言です。MVVM を使用しても、ビューのコード ビハインド クラスは 1 つしかありません。他の 2 つのクラス (はい、さらに 2 つある可能性があります) は、ビュー/デザイナーに直接関連付けられていないため、単純に "コード ビハインド" と見なすことはできません。

于 2012-07-12T06:15:12.647 に答える
2

短い答え: いいえ! ViewModel は、別のファイルの Codebehind と同じではありません。

適切な MVVM 実装では、コードビハインド、または少なくとも非常に小さなコードビハインドはありません。

ただし、ViewModel では、ウィンドウに直接アクセスすることはできません。MVVM では、ViewModel と View の間の通信は Binding を介して行われるため、(通常は) View への直接参照はありません。

MVVM は、ビュー中心のアプローチに対していくつかの大きな利点をもたらします。テスト可能で、変更がはるかに簡単で、アダプターです...

編集 そして、彼が本当にあなたのソフトウェアアーキテクトであるなら、彼はもっとよく知っているはずです...少なくともそれは私がソフトウェアアーキテクトに期待していたことです

于 2012-07-12T06:17:02.927 に答える
2

私もstakxとMare Infinitusに同意します。MVVM には多くの利点があり、複数のコード ビハインド ファイルを作成するだけではありません。

私の経験からすると、MVVM は WPF の機能を学習して使用するための最良の方法でBindingあり、. stakx が言及されている問題 (およびその他) がある Winforms スタイルで。CommandsStylesConverters

UnitTesting（アプリケーションでは非常に重要だと思います）、再利用性などとは別に、MVVMを使用することの非常に重要な利点の1つは、複数のビューをサポートできることです。つまり、アプリケーションに複数のUIをすべて使用できることです。同じViewModel; これは現在の要件ではないかもしれませんが、数年後には新しいインターフェイスが必要になるか、Silverlight や Metro などの他のプラットフォームをサポートする必要があるかもしれません。その場合、MVVM は多くの労力を節約します。

MVVM の実際の利点とその他のいわゆる利点について説明しているこの投稿を参照することをお勧めします (ただし、これらは実際には実際の利点であると思います) - MVVM Backlash

于 2012-07-12T07:36:06.043 に答える
1

1つの目的は、ビューなしでビューロジック（viewmodel）を単体テストできることです。

ここに、viewmodelの最初のアプローチに関するレイチェルからの1つの素晴らしいコメントがあります：

MVVMでは、ViewModelがアプリケーションであることを忘れないでください。ビューは、ユーザーがViewModelを操作できるようにするための美しいインターフェイスです。

于 2012-07-12T06:05:28.573 に答える
0

プロジェクトに 2 人しか参加していなくて、全員がオールインワンである場合、彼は正しいです。

しかし、デザイナーがコントローラー (または ViewModel) を台無しにしたり、プログラマーが何かにビューを変更したりしたくない場合は、プログラマーが設計を行うようにします。

さらに、膨大なテキスト ファイルを検索しなくても、どこを変更すればよいかすぐにわかります。

また、MVVM や MVC による分離はプログラミングの基本原則の 1 つであり、Data-Logic-View の分離であり、アーキテクトがそうしないように言う場合は、別のアーキテクトに依頼するときかもしれません:)

于 2012-07-12T05:58:48.497 に答える