特定のMVVMアプリケーションでフレームワーク（Caliburn.Microなど）を使用しないことを選択する方法は？
私はかつてMVVM/WPFプロジェクトを開始しました。これは最終的にビルドおよびデプロイされ、そのためにCaliburn.Micro MVVMフレームワークの多くを研究しました。事実は、私はそのためにCaliburn.Microを使用せずでなく、自分でいくつかのMVVMの概念（具体的には、ViewModelBaseとRoutedCommandクラス）。
今、私は同じラインに沿ってやや大きなプロジェクトに割り当てられました：言うまでもなく、「シングルユーザーリッチクライアントオフラインデスクトップアプリケーション」、そしてCaliburn.Microを使用することにしました。そして、そこが私の「問題」の始まりです。
私は この有名なブログ投稿 を読みました。そのタイトルは、「MVVMを使用している場合は、フレームワークが必要です必要です」 "、 それ：
「フレームワークなしでMVVMのようなことをしようとすると、膨大な作業になります。大量の重複したコード、車輪の再発明、および人々の考え方を変えるように再訓練 。
少なくともフレームワークを使用すると、コードの重複を回避でき、うまくいけば車輪を再発明する必要はありません。これにより、人々の再訓練に集中できるようになります。通常、再トレーニングの部分は避けられませんが、フレームワークは配管コードと構造を提供し、プロセスを簡単にします。 "
私は最初の読書に同意しますが、私のactualアプリケーションでのCaliburn.Micro（CM）の私のactual経験は無知であり、見当識障害。つまり、フレームワークはプロセスをまったく簡単にしませんでした。まったく逆です。かなり（あまりに）非公式なドキュメントでRob Eisenbergによって提供された繰り返しのある例を読み、複雑に提供されたサンプル、およびそれらが機能するように設計されているように見えるそれらの完全に間接的なクラスとインターフェイスの関係から使用パターンを推測しようとします副作用に基づいており、あなたが熟練した天才でない限り、人間的に不可能と思われます（暴言を言って申し訳ありませんが、私が何を言っているのか知っていると思います）。
ささいなシナリオには、IoCコンテナーが含まれているように見えることは言うまでもありません。これは、私がこれまで作業したことがなく、 私が持っていない問題を解決する のようです。私の問題やアプリケーションドメインについて考えるのではなく、それらのことを学ぶためにより多くのプロジェクト時間を費やすような気はありません。バナナが欲しかったのですが、CMからバナナのバスケットを持ったゴリラ（IoC）がもらえました。
私が実際に実装したい少数のMVVM固有のクラスのみで構成されている自作のMVVMフレームワークに戻ることを検討しているところで、ここで何かを失った場合に備えて、少なくともCMにチャンスを与えたいと思います。まったくの経験不足と無知から、明らかに「間違った方法」で物事を行うだけです。そして問題は：
「フレームワークは物事をより簡単でより自然にする」という幅広い合意がありますが、たまたままったく逆のことが起こった場合、これはフレームワークを使用するべきではないことを意味しますか、それとも間違った方法で学習しようとしているのですか？そもそもフレームワークを使うべきではないという手がかりはありますか？または、単純なMVVM開発でCMを使用する方法を理解するための「正しい」方法はありますか？
私はCaliburnMicroとMVVMLightを試してみましたが、Caliburnを使用しているときは、実際に感じていることを感じています。カリバーンは、この魔法のようなことをするためにはるかに行き過ぎており、何かがうまくいかないと、デバッグするのが本当に難しいので、事態をさらに悪化させます。
しかし、MVVMLightを使用すると薄くなり、使用すると、MVVMフレームワークとほぼ100％になり、いくつかの機能が組み込まれていることに気付くでしょう。
これはあなたの質問「フレームワークを使用しない方法」に答えないことを知っていますが、率直に言って、間違っているのでそのルートに進むことはお勧めできません。最初に。
MVVMとは何かを理解することが重要です。再実装（JPEGファイルの解析または特定のSQLデータベースサーバーへの接続）が不要な機能の一部は共有されていません。これはパターン-パターンの選択方法です。リッチなGUIを実装します。したがって、パターンの実装が単純で簡単な場合、フレームワークではなくパターンを使用することに恥を感じる必要はないと思います。
確かに、フレームワークとしてのパターンのアイデア全体が行き過ぎていると思います。何かがパターンになるためには、それがソリューションのクラスの一般的な形でなければなりません。これはそうであるため、パターンを使用するシステムに合わせてパターンを調整する必要があることが予想されます。万能のパターンを使用しようとすると、パターンを調整できません。パターンの実装をアプリケーション設計者に任せ、アーキテクチャーではなく機能をカプセル化するライブラリーを提供する方がはるかに建設的です。
WPFでの私の最初の経験はCaliburn.Microを使用していたので、これはおそらくほとんどの開発者とはかなり異なります。 WPFとCaliburn.Microの両方が、WinFormsに由来する非常に急な学習曲線であることがわかりました。現在Caliburn.Microが使用されていない別の組織で働いています。コードベースがかなり肥大化し、不必要に複雑になっている重複した配管コードがたくさんあることがわかります。
Caliburn.Microにはデバッグを複雑にするいくつかの問題があることは間違いありませんが、一度経験すると、再び苦痛を感じることはほとんどありません。開発速度の向上、よりクリーンで無駄のないコード、およびより良いMVVMを促進する全体的なフレームワークは、私にとってそれだけの価値があります。
Caliburn.Microはまた、ストックWPFを無効化しません-それはその上に構築するだけです。つまり、必要に応じてWPF機能を使用し、必要に応じてCaliburnをいくつかのビットに使用することができます。これは、私の頭の中でTypeScriptとJavaScriptが共存する方法に似ています。
機会があれば、私が将来取り組む新しいWPFプロジェクトでCaliburn.Microを使用することは間違いありません。
Caliburn.Microへの不満からここに到着した方は、このフレームワークをご覧ください。 Stylet
それはCaliburn.Microに触発されていますが、何が起こっているのかわからなくなってしまう多くの魔法を取り除きます。さらに、ドキュメントは、専門用語を使いたくないという前提なしに、はるかにわかりやすい言語で記述されています。初心者にはずっと良いです。
また、StyletはViewModel-Firstアプローチを採用しています。 Caliburn.Microおよび他の多くのフレームワークは、いくつかの厄介な問題を伴うビューファーストアプローチを採用しています。 SOLIDの原則とパターン化されたコードがすでに得意である場合は、ロジックがシステムを駆動する必要があるという観点から、つまり、見る。