4

最近、ビジュアル ツリーをたどることが悪い習慣であるというコメントをいくつか見ましたが (ここでは、たとえば)、これが悪い習慣である理由を見たり見つけたりしていません。

私が取り組んでいるプロジェクトでは、かなりのツリー ウォーキングがあるので、わざわざこれをすべて別のものに変更するか、そのままにしておくかを考えています。

したがって、ここでの私の主な質問は、ビジュアル ツリー ウォーキングが本当に悪い習慣であるかどうか、さらに重要なことに、そうである場合、なぜでしょうか?

また、視覚的なツリーをどこで (あるとしたら?) 歩けばよいでしょうか?

4

3 に答える 3

1
  1. ビジュアル ツリーをたどることは、多くの場合、WPF の "自然な" メカニズムによって提供される抽象化に割り込むことになり、フレームワークがそれ自体で行うべきことを (XAML 宣言、データ バインディングなどを介して) 手動で強制します。簡単に言えば、ハックです。場合によっては、WPF を適切に使用する方法がわからないことを示しています。(ちなみに、これは実際には使いにくいです)。

  2. ビジュアル ツリーが完成しているかどうかを常に把握できるわけではありません。WPF はまだすべてのコントロールを生成していない可能性があります (たとえば、リストに多くの項目を入力している場合など)。これを解決するには、セーフガードを実装しLayoutUpdatedたり、イベントを処理したりする必要があるため、コードが非常に複雑になります。

于 2012-08-17T10:21:25.567 に答える
1

まず、このテーマについてはさまざまな意見が寄せられると思います。

あなたがリンクした例では、その場合のビジュアルツリーウォーカーは間違った解決策だったと思います.WPFは通常、ある種のMVVMまたはMVPのようなパターンで使用するのが最適であり、それはデータバインディングを意味します.適切な構造を使用すると、ビジュアル ツリー ウォーキングで行った可能性のある多くのことをなくすことができます。

いわば「特殊効果」にのみ使用する傾向があります。私が取り組んでいる大きな内部 WPF アプリには、再利用可能な方法でいくつかの s にいくつかの便利な動作を追加する視覚的なツリー ウォーキング コードがありますItemControl(型パラメーターを使用して、それを機能させるのはとても楽しいです)。

また、特定のユーザーが UI の特定の部分を操作できるかどうかを制御するシステムの一部であるいくつかの添付プロパティの実装でビジュアル ツリーをたどります。これは、このシステムが、基になるデータの内容に関係なく、ビジュアル ツリーを変換する必要があるためです。ユーザーのアクセス許可は、基になるデータがすべてのステップで心配する必要のない分野横断的な問題です。

基本的には、UI 自体に何かを行うためだけにそれを行います - より便利な方法では実行できない UI の動作 (正直に言うと、ほとんどの場合、他のほとんどの方法の方が便利です)、または実際にビジュアル ツリー ベースを調整します。 UI がバインドされているデータでは都合よく表現できない要因について。データを操作する場合は、常にバックエンドのデータ構造または ViewModel で行います。

于 2012-08-17T10:28:44.853 に答える
0

それはあなたが視覚的な木を歩いている理由に依存します。ビューを自動化するメカニズムはたくさんあり、ほとんどの場合、非常に複雑な制御を行うのに十分です。

wpfでの長年の作業では、他の方法では実行できない(または他の方法が見つからなかった)非標準の動作を作成する場合にのみ、ビジュアルツリーウォーキングを使用しました。視覚的な木を歩くことは、他の例と同じように、たとえば反射のツールだと思います。それを知ることは良いことであり、その用途と欠点があります。

于 2012-08-17T10:30:10.017 に答える