階層データよりもLOBアプリケーションを構築するためのエレガントなUIパターン？

Question

私の質問は私が取り組んでいるWPFアプリケーションから来ているにもかかわらず、これはユーザーインターフェイスの設計とプログラミングパターンに関する一般的な質問です。

データモデルが階層型で階層が> 2レベル以上の場合、データ駆動型ユーザーインターフェイスを表示するためのきれいでエレガントなパターンは何ですか？最もクリーンなのは、繰り返しの少ないコード（すべてのデータモデルタイプのフォームをコーディングするのに比べて）が少なく、少しの退屈さを必要としないアプローチです。たとえば、反射に頼っているかもしれません。私はこれがネストされたデータグリッドを持っている理由だと思います。行の詳細テンプレートに子オブジェクトをネストすることができます。ほぼすべてのLOBアプリは階層的なデータに依存しているので、誰かが既にこの問題を解決しているに違いありません。

しかし、この問題は、マスターグリッドに多くの異なる子ディテールグリッドがあるとどうなりますか？ユーザーインターフェイスは詳細グリッドで混乱して見えることがあり、マスターグリッドにネストされ、互いの上に積み重ねられます。

私は、マスターグリッドにネストされたタブコントロールを試してみてください。別の方法は、新しいビューで新しいデータグリッドを開き、グリッドをネストしないことですが、最初にすべてのグリッドに対して新しいビューを作成するのは、私が避けようとしている退屈な作業のようです。

階層型データモデルで "text boxes over data" LOBアプリケーションを作成する代わりに、各ビュー（およびビューモデル）を1つずつコーディングする以外にも、クリーンな方法がありますか？

Answer 1

基本的に、これはツリーの表現方法に関する質問です。これに関する良い合意はたくさんありません。それは難しい問題です。確かに、ネストされたデータグリッドのアプローチは有効ですが、潜在的に複雑であると記述すると頭の爪に当たってしまいます。

ある程度、この質問に対する答えは、あなたが所与のレベルで対話しているときに必要なツリーの残りの部分に関するちょっとした情報と関係しています。 2レベル下の葉を使って作業しているとき、本当に樹木の根や根の子どもたちについて知る必要がありますか？確かにユースケースがあります。そのような場合は、（ネストされたグリッドアプローチのように）すべての子を表示するための表現構造を選択するのが理にかなっています。他のケースでは、ツリー内のより高いレベルに関する情報があればそれほど知る必要はありません。そのような状況では、より低いデータの提示をそれ自身のプレゼンテーション領域（ページ）に分離することは完全に意味をなさない。

この問題だけにはさまざまなアプローチがあります。 preziを見ましたか？非常に印象的で、印象的なことの一部は、データに「場所」の感覚があることです。複雑なデータや階層を理解するのに役立つ人間の空間感覚を使用しています。ズーミングは実際には空間的な方向性（時にはディスポジション）の意味で固定されます。

実際の質問では、 REST、特にHATEOASの期待を考えてください。実際には、プレゼンテーションとは無関係にデータをモデリングし、密集したビューモデルではなく、プレゼンテーションを比較的薄い層にすることを検討してください。調整が必要なものがいくつかあるかもしれませんが、最も重要なことは、全体的なビューモデルが調整する必要がある場合、戻って比較的簡単に変更できることです。同様に、データモデルは、与えられたデータセットに意味をなされる特定の構造を暗示する傾向があります。効果的には、データから構造を識別し、それに最も適したディスプレイモデルを見つけることです。作業のボートロードを厳格なビューモデルにコミットしないことにより、必要に応じて変更することができます。大まかに、アジャイルUIデザイン。

これは非常に主観的なもので、組織やニーズに大きく左右されます。すべてのソリューションには良い答えはありません。がんばろう;あなたは少なくとも正しい質問をしています！