WPF：イベント駆動型とMVVMの設計パターン
私は初心者のコーダーであり、数か月間WPFアプリに取り組んできましたが、学ぶべき時間の制約のためにMVVMに何かを実装するのに苦労していたため、方法を知る唯一の方法をプログラムにコーディングしました。カップリング、そしてたくさんのスパゲッティコード。
私のプログラムは、2万行以上の厄介な（ただし機能する）コードに成長しました。私が作成しているアプリはおそらく使用され、今後数年間開発が続けられますが、コードに取り組んでいるのは私だけです。
しかし、MVVMの学習を開始する時間があるので、MVVMパターンを追跡することが実際にどれほど役立つかを考えています。コードをMVVMパターンにリファクタリングすることを検討していますが、ほとんどのドキュメントでは、すべてを100倍にするのは難しいようです。コードビハインドと密結合を使用することで、UIに自分がやりたいことを正確に実行させることができ、すべてがイベント駆動型メソッドを使用して非常に高速にコーディングできるようです。
特に長期的には、WPFアプリのMVVM設計パターンに従うことがどれほど重要ですか？このアプリの再設計とMVVMパターンの追跡に時間を費やすことは私にとって良い考えだと思いますか？
perfect学習状況で自分を見つけたようです。現在、アプリケーションは機能しており、20k行のコードすべてに精通していると思います。変更を加えることはそれほど難しくなく、今のところ、開発アプローチを変更する理由は何もないようです。
あなたはカウボーイです！そしてカウボーイであることはとても楽しいです！
しかし、カウボーイであることは大変な作業であり、最高のカウボーイでさえ、しばらくするとSteamを使い果たします（混合されたメタファーについては申し訳ありません）。
質問では、アプリは今後何年間も使用および保守されると述べました。これらの2万行は確実に増加し、追加するすべての新機能、およびつぶすすべての新しいバグによって、既存の機能を損なうことなくコードを書くことがますます難しくなっていることに気付くでしょう。これは密結合スパゲッティ地獄です！
パターンとしてのMVVMは、開発者がコードを疎結合することを奨励します。 MVVMの世界では、モデルをビューステート（ビューモデル）および表示ロジック（ビュー）から分離します。これは行う事前に少し作業が必要ですが、ダウンストリームの利点はたくさんあります：
- モデルの単体テストは簡単です。心配する必要はありません。
- ビューモデルの統合テストは簡単です
- M、VM、およびVはコードの個別のセクションであるため、1つを変更すると、他の部分で回帰を引き起こす可能性がほぼ0％になります。
- そして、少なくとも7つの理由があります。
しかし、CBV（Cowboy View）経由でMVVMに切り替える最も重要な理由は次のとおりです。あなたは人間です。人間は実際にはソフトウェアのような複雑なもののメンタルモデルを作成するのが非常に得意ですが、そうすることは非常に骨の折れる作業です。また、頻繁に変化し、成長を続けるソフトウェアを追跡することは、精神疾患のレシピです。
私たちは肉の欠陥のある袋です。しかし、心配しないでください。私たちは肉の欠陥のある袋も組織化しているからです。
コードを単一の責任を持つクラス（ViewModelなど）に編成することで、メンタルモデルをロードすることなく、アプリケーションのサブセットで作業できるようになりますアプリケーション全体の。あなたの脳はこれをあなたに感謝します！
しかし、私の言葉をそれに取ってはいけません。この疑似暴言の冒頭で言ったように、あなたは完璧な学習状況にあります。あなたは古典的な間違いを犯しました（恥ずかしいことはありません）、あなたはそれがあなたに追いつくのに十分なほど長く続くでしょう。
必要に応じて、今すぐMVVMに切り替えます。またはしないでください。いずれにせよ、あなたは最終的にそれがなぜ有用なパターンであるかを学ぶでしょう。
私の推奨事項：カウボーイスパゲッティをできるだけ長く維持するようにしてください。学ぶための最良の方法は、間違いを犯すことです。だから、あなたの大きなものを早くそして頻繁に作ってください！
楽しんで！