MVP中渲染邏輯和業務邏輯之間的準則是什麼？

Question

我正在研究一個GWT應用程序，並被告知for循環構成了「業務邏輯」，不應該在MVP視圖的實現類中。所以作爲一種習慣，我從來沒有在我的viewImplementation類中使用for循環，而是將循環放在Presenter（Activity）中，並在viewImplementation類中調用一個方法來完成循環的每個迭代任務。

我知道演示者不包含小部件並具有業務邏輯。相反，viewImplementation類是您擁有這些小部件並保留渲染邏輯的地方，但是將for循環歸類爲業務邏輯的指南太嚴格了嗎？

是否存在使用GWT將MVP分類爲渲染邏輯和業務邏輯的一些指導原則？

Answer 1

我不同意「for循環構成業務邏輯」的說法。它是一種語法結構而不是業務邏輯。如果他正在發表聲明，那麼它遵循（IMO），您應該避免「If語句」以及。這是多麼實際和/或可行？！

業務邏輯就是放置在循環構造中，而不是構造本身。這一切都取決於你在循環中放置什麼樣的邏輯，這將是決定性的因素。

編輯

一個例子我能想到的表明你將如何找到一個for循環的圖，而根據「for循環」規則只應放置在模型。

想象一下，您想要製作一個帶有字母A-Z的工具欄，用戶可以點擊該字母來過濾搜索結果。

視圖負責應該如何顯示給用戶。出於這個原因，我會爭論使用以下for循環來生成視圖中的工具欄是最合適的方法。

僞碼

Let TB <- Toolbar control 
for letter = 65 - 90 (A - Z) 
begin 
     let item <- Toolbar Item 
     set item's text to letter 
     add item to TB 
end 

這似乎揭穿語句for循環總是構成業務邏輯，因此，必須將其放在模型內。