創建用戶和編輯用戶 - DRY或分離，更重要

我想知道更多有經驗的開發人員會考慮如何處理幾乎相同的流程，例如創建配置文件的用戶和編輯其配置文件的用戶。目前，我有一個單一的控制器方法和單一的視圖，處理新用戶和現有/編輯用戶之間的區別，只是通過傳遞$編輯標誌，所以我知道處理兩者之間的細微差異。在我的控制器方法和視圖中使用這些條件感覺有點混亂，但是它也感覺像是大量的重複來爲每種情況創建獨特的視圖和控制器方法。在這種情況下人們傾向於做什麼？創建用戶和編輯用戶 - DRY或分離，更重要

來源

2010-06-24 samwatt

當我建立一個可以創建新用戶的系統時，我傾向於只需要最少的註冊信息 - 例如電子郵件和密碼。

然後，網站的「配置文件」部分可以處理剩餘用戶詳細信息的所有編輯，而不必擔心這是新用戶還是現有用戶。

根據我的經驗，如果在開始時詢問太多問題，人們在註冊時往往會變得遲鈍！推遲沒有必要的事情，以後再收集這些信息！

來源

2010-06-24 23:09:01

有道理戴夫，這正是我通常會這樣做的，但在這個場合我有一個相當長的囉嗦（和必要的）登記表。或多或少，所有的註冊數據都可以在用戶註冊後編輯，這就是我的問題所促成的 - 更少的代碼，但有很多條件，或重複的代碼，而不需要條件！ – samwatt 2010-06-24 23:18:57

好的，你可以改變頁面的佈局來收集需要不同行爲的項目到一個或兩個較大的部分嗎？然後你有更少的條件存在，但仍然是同一個主要腳本。後端怎麼樣？理論上，你可以根據編輯/更新類型來改變表單的目標，或者再次將表單處理分離成基於條件的更大的塊。無論你選擇哪一種，聽起來像你需要大量的評論來提醒未來的編輯「如果你在這裏編輯，你也必須在那裏編輯」！ :) – 2010-06-24 23:48:09

我認爲你應該總是考慮設計決策的長期方面。

分離這些函數可能會更清潔，但您有兩個乾淨的函數。所以就美學而言，你可以以任何方式爭論。乾淨的重複代碼和可維護性之間存在着舊式的折衷。

然而，從長遠來看，還有其他考慮因素髮揮作用，您開始考慮風險。重複代碼的風險在於兩個代碼部分不同步，可能以微妙的方式難以檢測（例如，能夠添加在更新時被拒絕的數據）。如果你不是維護代碼的人，或者你很長一段時間沒有觸及代碼，這可能會更糟糕。

所以恕我直言，保持編輯標誌。你在一個地方擁有一切，儘管它是混亂的。

來源

2010-06-24 23:27:22

感謝您的答覆菲爾 - 認爲我會保持編輯標誌，特別是在過程中有最小的差異。 – samwatt 2010-06-24 23:59:57

我通常對ORM進行編碼，以便代碼可以愉快地分配信息，並且不關心它是新對象還是現有對象。當調用最後一個'save（）'時，對象本身會判斷它是否執行了'UPDATE'或'INSERT'。 – staticsan 2010-06-25 06:12:31

我不一定會將編輯標誌稱爲「凌亂」，並且它比複製代碼更爲可取，正如Phil所說的那樣 - 可能會造成嚴重破壞。爲了規則的緣故，DRY沒有被髮明爲規則。這是整個軟件開發歷史中感受到的許多痛苦的總結。 – 2010-06-25 07:15:23

創建用戶和編輯用戶 - DRY或分離，更重要

回答

相關問題