ニュースレターアプリケーションを作成しています。まず、プログラムを起動すると、「メッセージ」と「受信者」の2つのメインボタンが表示されます。クリックした内容が何であれ、別のコンテンツが表示されます。
私の質問は、最初のウィンドウを非表示/閉じて、別のウィンドウを作成/表示する必要がありますか、それともコントロールの表示を変更するだけですか？
私のような小さなアプリケーションの場合、コントロールの可視性を変更するだけで十分だと思われるかもしれないので、私は別の考えを持っています。しかし、実際には境界がどこにあるのか、アプリケーションが十分に小さいのかどうかはわかりません。[メッセージ]をクリックすると、メッセージのリストが表示され、メッセージを操作するためのさまざまなオプション（参照、削除、編集、追加、並べ替え、フィルタリングなど）が表示されます。他のボタンもほぼ同じですが、受信者が対象です。
通常のアプローチは何ですか？私の場合は何がいいでしょうか？
とにかく、これはすべてほとんど瞬時に行われるため、パフォーマンスや速度については考えていないと思います。
正しい「アプローチ」は、アイテムのリストを表示できる汎用コントロールを持ち(私は考えていますItemsControl)、これをカスタムモデルオブジェクトの監視可能なリストにバインドすることだと思います。これらのモデル オブジェクトにはテキストが含まれ、GUI から呼び出される 、 など (私は s と考えています) のようなメソッドがありbrowseます。1 つのタイプの項目を表示する場合は、ObservableList (バックグラウンド ロジックのどこかに作成したもの) を DataContext に入れて、表示できるようにします。deleteeditCommandItemsControl
これは、WPF アプリケーションで通常採用される通常の MVVM アプローチです。シンプルに保ちたい場合、または MVVM の経験がない (そして経験を積みたくない) 場合は、可視性を変更するか、たとえば TabControl を使用してビューを別のタブに配置するかは問題ではないと思います.
WPF は非表示のアイテムをアンロードするため、可視性を変更してアイテムを非表示にすると、実際にはコントロールがアンロードされ、再度表示すると再ロードされます。つまり、実際の違いはオブジェクト自体の作成のみであるため、2 つのパフォーマンスの違いはほぼ同じです。
私の通常の好みは、オブジェクトが何であれバインドされContentControlている単一のものを使用し、必要に応じて別のものに交換することです。これにより、可視性やウィンドウ管理をいじる必要がなくなり、私の生活が楽になります。ContentActiveWindowActiveWindow
しかし、それは間違いなく「ルール」ではありません。私は通常、アプリケーション フローに最適な方法を実行し、コントロールのロード/アンロード時に重大なパフォーマンス ヒットに気付いた場合にのみ心配します (これは、新しいアイテムを作成するか、その可視性を切り替えるかに関係なく発生します)。
これらの特殊なケースでは、各アイテムの をメモリに保存し、再表示する必要があるときに、アイテムを再作成する代わりにメモリからリロードする、カスタマイズされた拡張を使用します。TabControlContentPresenterこれにより、コントロールの再描画のパフォーマンス ラグが修正されますが、アプリケーションがより多くのメモリを使用するようになるため、ビューを切り替えるときに実際にパフォーマンスの問題に気付いた場合にのみ使用します。
速度またはメモリ消費量のどちらを好むかに基づいて決定する必要があります。
あなたのような小さなアプリケーションの場合、私はそれについてあまり心配しません。コントロールが非常に小さい場合、速度やメモリの違いにさえ気付かない可能性があります。