2011-07-08 62 views
2

這是關於用戶界面設計和編程模式的一般問題,即使我的問題來自我正在處理的WPF應用程序。用於在層次數據上構建LOB應用程序的優雅UI模式?

當數據模型是分層結構且層次結構深度> 2級時,什麼是乾淨優雅的模式來呈現數據驅動的用戶界面?最簡潔的,我的意思是一種只需要很少重複代碼的方法(與爲每種數據模型類型編寫表單相比),並且需要很少的乏味。例如,它可能依靠反思。我想這就是爲什麼我們有嵌套的數據網格。您可以在行詳細信息模板中嵌套子對象。幾乎所有的LOB應用程序都依賴分層數據,所以有人必須已經解決了這個問題。

但是,這個問題是,如果主網格有許多不同的子細節網格?用戶界面可能看起來與細節網格混亂,嵌套在主網格中並堆疊在彼此之上。

我的一些想法可能是嘗試嵌套在主網格中的選項卡控件。另一種方法是在新視圖中打開一個新的數據網格,不要嵌套網格,但是再次爲每個網格創建一個新視圖看起來就像我試圖首先避免的那種單調乏味的工作。

除了對每個視圖(和視圖模型)逐個編碼之外,是否還有一種更清晰的替代方法來構建「text boxes over data」LOB應用程序而不是分層數據模型?

回答

1

基本上,這是一個關於如何表示樹的問題。這方面沒有很好的共識。這是一個棘手的問題。當然,嵌套數據網格的方法是有效的,但是當你把它描述爲可能混亂時,你會頭痛目眩。

在某種程度上,這個問題的答案與您在特定級別進行交互時需要多少樹的其他信息有關。你真的需要知道樹的根,以及根的所有孩子,當你在做什麼時會留下兩層?當然有你使用的用例,在這種情況下,選擇一個表示結構可以讓你看到所有的孩子(就像在你的嵌套網格方法中一樣)是有意義的。在其他情況下,如果有關樹中更高級別的任何信息,則不需要知道太多;在這些情況下,將低層數據的表示隔離到其自己的表示區域(頁面)是非常有意義的。

只有這個問題有各種不同的方法。你見過prezi嗎?這令人印象深刻,令人印象深刻的部分原因是數據存在「地位」的感覺;它利用人類自身的空間感來幫助理解複雜的數據和層次;縮放真的會鎖定在空間取向的意義上(偶爾會出現取向)。

根據你的實際問題;想想REST,特別是HATEOAS的期望。實際上,考慮獨立於演示文稿建模數據,然後讓演示文稿成爲一個相對較薄的層,而不是密集的視圖模型。有些東西可能需要調整,但最重要的是,如果整個視圖模型需要調整,則可以相對輕鬆地返回並修改它。同樣,數據模型傾向於暗示某個特定的結構對於給定的數據集合是有意義的;有效地,這是一個從數據中辨別結構的問題,並找到最適合的顯示模型。通過不將工作量付諸嚴格的視圖模型,您可以根據需要進行更改。敏捷的UI設計,大致。

這東西是非常主觀的,它真的取決於你的組織和你的需求;對於每個解決方案都沒有一個好的答案。祝你好運;你至少在問正確的問題!

+0

我現在看到,viewmodel通常可以是我的應用程序中最靈活的部分,也是我最控制的部分。 UI控件和模型相比之下是相對靜態的,特別是如果控件是第三方的話。 UI控制的顯示選項甚至可以驅動視圖模型的設計。有或沒有數據網格會影響應用程序的呈現,並且視圖模型會相應地改變。 –

相關問題