2

例でやってみましょう。従業員を取得する機能を持つ Company エンティティを考えてみましょう - getEmployees()。会社には多くの従業員がいる場合があるため、会社に負荷がかかると従業員は負荷されません。ただし、従業員が読み込まれると、それらはキャッシュに保存され、次の呼び出し時にすぐに取得されます。

ここで、従業員のリストをリスト ビュー (GUI) で表示したいと思います。

従業員がインターネットからロードされている間、「ロード中」の表示を提供したいと思います。

しかし、キャッシュから (非常に高速に) ロードされると、'ロード中' インジケータを表示してすぐに削除するのは面倒です。したがって、すでにロードされている場合は、「ロード中」インジケータをまったく表示したくありません。

この設計上の問題にどのように取り組みますか? メソッドを追加しますgetCachedEmployees()か?おそらくisEmployeesCached()?おそらくメソッドをに変更しgetEmployees(boolean cache)ますか?

キャッシュをカプセル化する代わりに、キャッシュが強調され、ソフトウェアが複雑になるため、上記のいずれも好きではありません。

他のアイデアはありますか?

4

1 に答える 1

2

GUI 要素を表示および管理するための GUI とコードが、アプリケーションのロジックとデータから切り離されていると仮定します。

GUI の何らかのアクションがアプリケーション ロジックをトリガーして従業員をロードする場合、getEmployees() メソッドを呼び出すだけでよいことを理解しています。GUI は、データがキャッシュまたはインターネットから読み込まれるかどうかを制御するべきではありません。ただし、ロード表示を表示する必要があるかどうかを判断するには、GUI にロジックが必要です。

私が考えることができる最善の解決策は、GUI にタイマーのようなものがあることです。getEmployees() メソッドを呼び出し、500 ミリ秒待機し、データが既に返されている場合は直接表示します。これまでにデータが返されなかった場合は、読み込みインジケーターを表示する必要があります。ここで非同期呼び出しとコールバックが必要になるため、おそらくここで同期を行う別のクラスのようなものが必要になるでしょうが、それはおそらく努力する価値があるでしょう。

私は .NET/C# に似たようなものを実装しました。ここでは、他の特別な条件も真である場合に、500 ミリ秒の待機時間の後にのみアクションがトリガーされます。アプリケーションを使用する場合、ユーザーは GUI の反応が少し遅れることに気付きますが、全体的なルック アンド フィールが損なわれることはありません。

ちなみに、GUI に getEmployees() メソッドを 1 つだけ表示するアプローチが気に入っています。このようにして、GUI とアプリケーション ロジックを厳密に分離することができます...

于 2012-08-29T14:44:54.933 に答える