1
越來越多的框架正在試圖導航規則從代碼中分離出來。例如,JSF在faces-config.xml中獲得了「導航規則」標籤來控制頁面流。新的xcode 4.2引入了故事板,因此開發人員不必編寫代碼來處理場景之間的導航。 我的問題是爲什麼分離導航流程和代碼非常重要。在控制器中編寫代碼以處理頁面流時出了什麼問題?爲什麼單獨的導航規則
越來越多的框架正在試圖導航規則從代碼中分離出來。例如,JSF在faces-config.xml中獲得了「導航規則」標籤來控制頁面流。新的xcode 4.2引入了故事板,因此開發人員不必編寫代碼來處理場景之間的導航。 我的問題是爲什麼分離導航流程和代碼非常重要。在控制器中編寫代碼以處理頁面流時出了什麼問題?爲什麼單獨的導航規則
關閉我的頭頂:具有在一個地方指定的導航流程更容易理解代碼庫你不熟悉的 - 你可以清楚地看到如何可以得到給定的視圖,而不必尋找這下來。
你提到XCode中的故事板編輯器 - 另一個好處是,具有導航結構作爲第一類實體使得它好的工具。
如果你的框架(也許是一個空的Java頁面流框架?)也檢查用戶是否堅持這個流程,可以很容易地發現如果違反預期流程會發生的錯誤。相比,「直接的」代碼(例如,如果用戶試圖打開「嚮導」類型的交互的中間。)
使用這樣的框架施加了認知開銷。這並不意味着您應該忽略高於「控制器方法代碼」的抽象級別的模式,否則您會直接將代碼轉換爲意大利麪條代碼。很顯然,正規化導航流的好處隨着應用程序中視圖的數量以及它們之間連接的複雜性而增加。
需要注意的是JSF 2.0的隱式導航消除那些冗長的XML導航規則。 – BalusC