我正在研究一個應用程序,允許來自公司不同部門的不同人員登錄和編輯表單。每個部門都具有隻允許他們編輯和查看的特定字段。分割軌道模型與使用一個模型組合形式
如果我爲整個字段集合創建一個模型,並根據誰登錄,呈現包含必要字段的不同表單,它會更有組織的代碼嗎?或者將部門特定領域分成他們自己的模型,然後根據誰登錄,渲染一個包含其特定領域的表格,並通過某種外鍵將不同部門的記錄聯繫在一起,會更好?
我正在研究一個應用程序,允許來自公司不同部門的不同人員登錄和編輯表單。每個部門都具有隻允許他們編輯和查看的特定字段。分割軌道模型與使用一個模型組合形式
如果我爲整個字段集合創建一個模型,並根據誰登錄,呈現包含必要字段的不同表單,它會更有組織的代碼嗎?或者將部門特定領域分成他們自己的模型,然後根據誰登錄,渲染一個包含其特定領域的表格,並通過某種外鍵將不同部門的記錄聯繫在一起,會更好?
我會拆分字段,然後您可以使用accepts_nested_attributes_for設置您的模型以適當地構建您的表單。
「這取決於」可能是最好的答案。 你有幾個領域?每個部門表單類型有多少邏輯?
如果您將所有字段拆分爲不同的模型(以及相應的表格),如果您希望在填充表格後全面瞭解這些表格,那麼這將變得很麻煩,因爲它們將位於不同的表格中。您必須通過表單的每個組織才能獲得完整表單。
如果您仍想分割它們,因爲每個部門都有很多邏輯,您可以使用table_name將所有模型指向包含所有字段的「主」表。這樣您就可以將所有數據都放在一張表中,並且可以輕鬆檢索。但是,您還必須保存表單的類型以便以正確的模型檢索它,可能比它的價值更麻煩。 (如果將所有字段保存在一張表中最好的方式也取決於它,它會多久檢索一次還是更頻繁地插入/更新)。
簡單形式在一個模型中可能會很合適。除非每個部門有很多不可共享的代碼,否則將表單拆分爲不同的模型可能不值得。如果您將表單拆分爲模型,那麼您可能應該創建一個主表單模型,並讓部門模型將其擴展爲可重複使用的表單邏輯。
畢竟,我會說,我更喜歡簡單性,所以我可能會將它保存在一個模型中。