アプリケーションのメインビューに機能を追加しているときに、コードの量がすぐに問題になることに気付きました（現在、ビューモデルには約600行のコードがあり、まだ追加するものがたくさんあります）。
ビューをより小さなコンポーネントに分割/設計する方法に関する記事を探していましたが、満足のいく解決策が見つかりませんでした。ある人は子ビューモデルの使用を提案しましたが、それは他の問題（ビューモデル間の依存関係）を示しました。
ユーザーコントロールを使用することを考えましたが、他のビューで使用するビューには何もないため、ユーザーコントロールの目的が損なわれます。
この状況での正しいアプローチは何ですか？
ありがとう、エイドリアン
ビューをコンポーネントパーツに分割する場合は、ビューの構成を行う必要があります。MVVMアプリを構築している場合は、実際にはMVVMフレームワークを使用している必要があります。Caliburn.Microのようなものは、ビューの構成を非常に簡単にします。
ビューモデル間には必ずしも依存関係がある必要はありません。ビューを生成するために必要なものだけを知っている必要があります。これは、親ビューモデルに含まれるビジネスオブジェクトのサブセットである可能性があります。親ビューモデルにはすべての子ビューモデルへの参照があるため、構築時にビジネスオブジェクトの関連部分を渡すことができます。
CaliburnMicroの使用に同意します。
ただし、悪魔の代弁者を演じるには、ViewModelファイルを別々のファイル（同じクラス名）に分割し、キーワードのpartial前にclassキーワードを使用することができます。その一般的にきちんとしていて、別々のクラスに分割することからの1つのステップアウェイ（非破壊の前駆体）。
また、Caliburn.Microは、アプリケーションをより小さなコンポーネントに分割するための優れたソリューションであることに同意します。
Caliburn.Microでは、ビューモデル間の通信はイベントアグリゲーターパターンに基づいています。
これにより、ビューモデル間の結合が緩くなります
分割は理想的ではありません。
Caliburnツールキットがイベントに焦点を合わせているように見えますが、私のアプリケーションは主にICommandの実装に依存しています。
私にとって、Caliburn.Microとの最初の出会いは満足のいくものではありませんでした。私はVS2010プロを持っているので、セットアップはVS2010に合わせて調整されているように見えました。しかし、Silverlightのセットアップで迷子になりました。Prismのようなツールキットと比較すると、起動が簡単ではありません。今すぐ切り替えるには時間がかかります。私は独自のMVVMパラダイムを使用しています。これは、Caliburnよりも抽象的ではなく、あらゆる場所で多言語サポートを統合しています。また、Binding / DataContextパラダイムの性質により、一部のソースが大きくなりすぎるという1つの許容可能な問題に直面しています。この問題については、「部分クラス」が解決策であることを認めます。より洗練された解決策があることはわかっていますが。
仕事の真っ最中、別のツールキットに変更することはできません。
そのため、MicrosoftがそのBinding/DataContextパラダイムの柔軟性を高めるのをやさしく待ちます。
Caliburnが、ビューモデルをいくつかのアイテムに割り当てるより多くのインテリジェンスを示している場合があります。しますか？（そうだと思います。）
別のオプションとして、どのコントロールがどのビューモデルに割り当てられるかをカスタムアロケータでトリガーするカスタム（xaml使用可能）オブジェクトを定義することもできます。どのようにそのことについて ？