私は複合 WPF アプリケーションに取り組んでおり、コードをアセンブリに分割するための適切なガイドラインを読んだところです。この記事の著者は、可能な限りアセンブリの数を最小限にすることを支持しています。
アセンブリの数を最小限に抑えながら、コンポジット WPF アプリケーションを合理的にモジュール化するバランスをどのように取っていますか?
現在のプロジェクトでは、機能の論理グループごとにモジュールを作成することから始めました。これにより、かなりの数 (14) の小さなアセンブリが作成されます。これをリファクタリングしてアセンブリを最小限に抑えようとすると、コンポジット WPF アーキテクチャを維持しながら 6 まで下げることができますが、柔軟性が失われているのではないでしょうか... YAGNIを覚えておく必要があるかもしれません。
YAGNI の他に、関心の分離と遅延読み込みパターンも覚えておいてください。アプリケーションのさまざまな側面に属する、潜在的に不要な機能を多数バンドルするアセンブリを少なくしても意味がありません。また、一緒に属していない同じアセンブリ機能にバンドルすることでバグを誘発するリスクがあるため、低結合を維持するコードを維持する方がはるかに簡単であることも覚えておいてください。
アプリケーションの典型的な使用シナリオでいくつかのユーザビリティ テストを実行し、どのモジュールが頻繁に一緒に必要とされるかを調べたり、相互に依存したり、相互に継承したり、これらを同じアセンブリにバンドルしたりすることができます。ばらばらの機能を持つモジュール - 選択を行うと、どちらか一方をロードすることになりますが、両方をロードすることはありません。特に、別々のアセンブリに保持する必要があります。
コードを必要な数だけアセンブリに分割して、コードを理解しやすく維持しやすくします。後でアプリケーションのパフォーマンスの問題を発見し、その原因がアセンブリの数が多すぎる場合、それらのいくつかに参加することを考え始めることができます。使用するアセンブリの数に関係なくコードを見失うことがないように、オブジェクト モデルの設計と名前空間の構造を明確にするようにしてください。