演示邏輯vs UI邏輯

任何人都可以澄清這些條款。
我發現它們非常模糊或與上下文相關。演示邏輯vs UI邏輯

例如，我們有一個VM與項目列表。該選擇不僅影響按鈕的可訪問性（即，命令可以執行），還影響VM的行爲：重要的是一個或多個項目需要同時編輯。

第二個示例是創建新項目的過程。
在用戶提供數據後，我們將項目添加到項目集合中，從而將其插入到列表中，並希望將其選中並聚焦。現在我們通過爲項目的VM引入IsSelected和IsFocused屬性來完成此操作。真正的工作是通過視圖通過綁定，附加屬性和行爲完成的。

我們的團隊insits的一些成員，加入這類性質的（IsVisible，IsSelected，IsFocused的等）到虛擬機帶來的UI邏輯虛擬機，因爲UI和表示邏輯混合是不是一個好的做法。

對於我來說，遵循模式是重要的，但更重要的是不要重複自己。我更喜歡綁定和代碼隱藏中的幾行，而無需將DataContext轉換爲具體的VM類型，調用VM的方法等。

不過，我不喜歡HolyWars，並承認由於誤解了這兩個術語以及相互分離的標準，我可能會錯。

來源

2013-02-01 Pavel Voronin

http://en.wikipedia.org/wiki/Presentation_logic對我而言，演示文稿看起來像UI邏輯http://en.wikipedia.org/wiki/User_interface – kenny

我認爲在VM中放置表示邏輯非常重要，並且在其上具有像IsEnabled這樣的屬性，因爲這樣可以測試它。這也降低了視圖的複雜度，從而減少了無法進行單元測試的代碼量。此外，我會對你的同事可能會有關於爲什麼虛擬機中的表示邏輯不是最佳實踐的任何引用感興趣。恕我直言，用戶界面是表示層的一部分，虛擬機的目的是爲視圖建模。因此，在這裏放置表示邏輯似乎很自然。

附加編輯：

從Implementing the MVVM Pattern

視圖的責任是明確的用戶在屏幕上看到什麼樣的結構和外觀。理想情況下，視圖的代碼隱藏僅包含調用InitializeComponent方法的構造函數。在某些情況下，代碼隱藏可能包含UI邏輯代碼，這些代碼實現了可擴展應用程序標記語言（XAML）中難以或低效表達的可視行爲，例如複雜動畫，或者代碼需要直接操作視覺元素視圖的一部分。你不應該在視圖中放置任何你需要進行單元測試的邏輯代碼。通常，視圖代碼隱藏中的邏輯代碼將通過UI自動測試方法進行測試。

來源

2013-02-01 09:23:17

不確定是從VM控制選擇還是焦點是一種演示邏輯。這就是爲什麼我要求澄清這些條款。 –

他們可能是對的。但我認爲將這種邏輯放入虛擬機可以使測試變得更加簡單。尤其是如果控制狀態是由業務邏輯決定的。 –

@voroninp我同意大衛，像控制選擇和焦點的東西是用戶界面/表示邏輯。虛擬機用於「控制」域和UI之間的交互。他們是否建議將該代碼放在視圖本身中？ – kenny

演示邏輯vs UI邏輯

回答

相關問題