Symfony2表單組件 - 違反MVC和SRP？

Question

我越是使用Symfony2並且與它的形式斗爭越多，我得出的結論是它們是一個巨大的可怕的野獸，甚至不應該存在。

我在這里發現了這篇文章，我發現我同意作者。 即使該文章是針對Symfony 1.x，我認為它仍然適用於Symfony2中的Form組件。 看起來表單組件似乎試圖在一個地方解決屬於模板，控制器和模型的問題。 這不是嚴重違反MVC和/或SRP（單一責任原則）嗎？

這可能是一個不同的問題，但我覺得它有點相關 - 我也注意到symfony的許多可用包試圖解決視圖外的視圖問題，例如：

KnpMenuBundle - 您在服務器端使用oo接口生成菜單（為什么不在它們所屬的視圖層中？）

IvoryCKEditorBundle - 將textarea轉換為ckeditor是在視圖文件中的一個jquery行中完成的，那么為什么這個bundle存在呢？ 我甚至不想計算那里的行數。

所以在Symfony的核心區域似乎有這些違規行為，或者我只是沒有得到它？

Answer 1

表單處理的問題在於它違反了MVC的定義。 這是一個被稱為“橫切”的問題，並且過去已經通過科學進行了研究。 例如， 使用WebJinn進行Domain Driven Web Development的文章是關於該主題的有趣讀物。

舉個例子，考慮一下表單與MVC不同層的關系：

模型：

• 表單復制域模型（DM）的信息結構 。 如果更改此結構（例如，通過向數據結構添加字段或向過程添加參數），則還必須調整表單以輸入該信息。
• 他們需要來自DM的類型信息 ，以將輸入轉換為所需的類型。
• 他們需要知道DM中指定的約束來驗證輸入。
• 理想情況下，它們直接從/向DM讀取和寫入數據（例如，通過讀取/寫入數據結構的字段或通過調用DM中的過程並將提交的值作為參數）。

控制器：

• 表單接收提交的數據並將其發送給DM。
• 他們根據是否成功驗證來改變程序流程。

視圖：

• 表單呈現為HTML標簽和屬性的復雜結構，取決於以上所有（應該是否需要字段？是否應顯示錯誤？如何訂購字段？在下拉列表中提供哪些選項？等等）

因此， 不可能編寫不觸及所有這些層的表單抽象機制。 相反，解決方案是根據MVC將表單庫本身構建到實現SRP的不同層和子組件中。 如果您查看Symfony2 Form組件，它會很好。 ;）

那為什么它是一個“巨大的可怕的野獸”？ 第一個問題是抽象問題。 想象一下簡單的下拉菜單。 如果我們想重用下拉代碼，我們需要以某種方式對其進行抽象。 現在查看上面的列表，即使這個簡單的輸入也會觸及MVC應用程序的所有三個層。 你如何抽象出一些有意結構化為三個不同部分的東西？

第二個問題是特征多樣性。 表單庫從未解決開發人員在日常生活中遇到的所有問題。 因此，所有這些層和抽象機制都需要是可擴展的，以便您可以使它們的行為與您希望的完全相同。

雖然可擴展，但Form組件已經解決了數百個您甚至不必考慮的微小問題。 如何輸入日期，如何使用不同的UI（下拉菜單，復選框，單選按鈕等）選擇一個或多個選項列表，如何再次保護表單安全漏洞以及更多我可以撰寫論文的主題關於。

您看到表單庫變得非常復雜。 我們編寫這種“大型可怕的野獸”的最佳選擇是讓初學者的API盡可能簡單，盡可能靈活地為更高級的用戶提供，並撰寫有關利用其全部功能的大量文檔。 最后一點肯定還缺乏（ 請幫助！ ），但我們一直在努力完成上述所有工作。

另一方面，遺憾的是，將復雜問題簡化為簡單問題是不可能的。

那些更簡單的其他表單庫怎么樣？ 在我看來，這些甚至沒有試圖解決Symfony2 Form組件已經為您解決的大多數問題。 :)

2014年1月24日更新：對於任何想要了解更多（更多）的人，這是我發表的關於這個主題的論文 。