【WPF】DIYプログラミングでMVVMを推奨しない理由

当ページのリンクには広告が含まれています。

WindowsForm を使ったデスクトップアプリは気軽に作れて開発の敷居も低いのですが、PCやタブレットなどの異なった解像度での表示ではデザインが崩れるという課題もあります。

そこで、WPFでデスクトップアプリを開発しようという方も多いのではないでしょうか。

WPF といえば MVVM というデザインパターンの利用が推奨されていますが、学習コストを掛けてMVVMを習得する必要があるのでしょうか?

私の答えは「ノー」です。

少なくともDIYプログラミングにおいてMVVMのメリットは生産性を落とすだけで逆効果です。

今回は、その点について私の考えを解説したいと思います。

目次

WPFとMVVM

プログラムを作る上に置いて、プログラムの目的ごとに「プログラムの考え方やプログラムの構成」が色々とパターン化されています。

これをデザインパターンと呼んでいるのですが、MVVMは(Model-View-ViewModel)はデザインパターンの1つです。

詳しくは「世界で一番短いサンプルで覚えるMVVM入門 」の記事をご覧頂くとして、要するにWPFを使ったプログラミングはMVVMと呼ばれるデザインパターンが推奨されています。

WindowsやWord、Excelなどのオフィス製品をはじめ、大人数で開発されているデスクトップアプリケーションの多くでMVVMが使われています。

MVVMは大規模開発でのみ有効な手法

MVVMが登場した背景は、数十人~数百人規模の開発における生産性向上です。

複雑且つ大規模化するアプリケーション開発において、デザイナーとプログラマーを分業化し、後々の仕様変更に対して容易に対応できるよう、デザイン部分とロジック部分を分離するという考え方になっています。

別の見方をすると、デザイン部分とロジック部分するための仕組みをプログラムに組み込んであげる必要があるのです。

DIYプログラミングはそもそも個人が自分に役立つプログラムを作るものですから、開発は1人~数人がほとんどです。まして専属デザイナーいて、プログラミング作業と分業するようなこともありません。

にもかかわらず、MVVMに関する学習コストをかけてデザイン部分とロジック部分を分割し、プログラム随所にMVVMのルールに則ったコードを埋め込んでいくという作業は、明らかにオーバースペックです。

これは、自転車で10分走れば到着できるような場所に、40人乗りのバスを1台借りて行くようなものです。

では、次に簡単なサンプルプログラムを使って検証してみましょう。

従来の方法とMVVMはこんなに違う

今回作ったプログラムはボタン1個とテキストボックス2個で構成されていて、

  1. 上段のテキストボックスに任意の数値を入力
  2. 計算ボタンをクリック
  3. 下段の敵うとボックスに二乗された値が表示される

というものです。

画面例では、100が入力されていて、100が二乗された答え=10000が下段に表示されています。

従来のイベントを使ったサンプル

従来の方法というのは、WindowsForm で慣れ親しんだイベントハンドラにプログラムを書いていく方法です。

画面に張り付けたコントロールに固有の名前を付与しておいて、イベントハンドラでは名前を使ってコントロールにアクセスし、計算結果を表示するという方法です。

WindowsForm技術者なら、この方法は直感的に分かりやすいと思います。

では、Xamlから見ていきましょう。

次に、ソースコートです。

今回はCalcというクラスに値を入れるという事を強引にやっていますが、これはMVVMのサンプルと記述を統一するために行っている処理なので、それ以外に意味は有りません。

uxCalc_Click というイベントハンドラで計算を行い、画面に表示しています。

MVVMを使ったサンプル

次はMVVMのサンプルです。

MVVMはコードがコードが長くなるので、生産性を高めるためのフレームワーク(Prism、Livet 他)を使いますが、今回は標準機能だけで作っています。

では、Xamlから。

次はソースコードです。コメントを入れると見た目上ソースコード量が増えたような印象を受けますので、今回は省いています。

それでも従来の方法に比べると圧倒的にソースコード量が多くなることが実感できるのではないでしょうか。

Prismを使ったMVVMのサンプル

標準機能だけでMVVMをすることは生産性が低すぎるので、通常はMVVMフレームワークを使います。今回は、prism というフレームワークを使ってソースコード量が減った(効率化された)サンプルも提示しておきます。

まずはXamlからですが、参照設定に

が入っている以外は、標準機能だけのMVVMとまったく同じです。

次はソースコードです。

Prismを使う事でかなりシンプルになったことが分かると思います。

でも、やっぱり従来方式に比べてソースコードが長くなりがちですよね。

まとめ

以前、マイクロソフトが主催するWPF関連のセミナーを受講した時に次の様な事を言われてました。

  • MVVMは学習コストがそれなりに必要なので、プロジェクトの状況(期間、予算、MVVM習熟度)に応じて従来(イベント)方式とMVVMのどちらを採用するか決めれば良い。
  • 1つのプロジェクトで従来方式とMVVMを混在するのは、メンテナンス性に欠けるので避けてください。

MVVMは分業の必要があるような大人数・大規模開発で初めて効力を発揮するため、小規模少人数での開発だと無駄が多くなります。

DIYプログラミングにおいてはデメリットの方が大きいというのがお分かりいただけたかと思います。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次