對使用或不使用嵌套屬性感到困惑

Question

我想知道嵌套屬性的用例。 使用與不使用的優缺點。

我有一個有很多has_many關聯的 model。 例子：

class Post
  has_many :visitors
  has_many :pageviews
  has_one  :metric
end

盡管我喜歡只發送一個請求並使用正確的關聯創建所有這些東西的想法，但我不喜歡所有visitors 、頁面pageviews和metric的創建都在PostsController中的想法。 我非常喜歡關注點分離。 在處理嵌套屬性時，我應該遵循什么明確的規則嗎？

謝謝你。

Answer 1

我認為你正在做一個你不需要的飛躍。

我不喜歡訪問者、瀏覽量和指標的所有創建都在 PostsController 中的想法。

他們不應該也不必是。 事實上，它們從來都不是默認的。

在控制台中運行rails routes ，您會看到每個has_many模型都有自己的控制器和視圖。

很少有我有一個 web 應用程序和一個 model 沒有並使用自己的 controller。

像/posts/:id/visitors這樣的路由應該指向visitors#index ，而不是posts#visitors

如果您將所有內容都放在一個 controller 中，我認為您實際上並不是在嵌套，而是在擴展。

我認為關系數據庫的意義在於建立關系，所以限制你的關系似乎有點自我限制。

Answer 2

我認為您一開始並沒有真正掌握嵌套屬性的用途。 當您需要在單個請求中對資源及其子項進行 CRUD 時使用它。

它的使用實際上是由用戶體驗要求決定的。 有時您實際上需要一個表單，例如這個非常常見的訂單表單示例：

class Order
  has_many :line_items
  accepts_nested_attributes_for :line_items
end

class LineItem
  belongs_to :product
end

<%= form_for(@order) do |f| %>
  <%= f.fields_for(:line_items) do |ff| %>
    <%= ff.number_field :quantity %>
    <%= ff.collection_select :product_id, Product.all, :id, :name %>
  <% end %>
<% end %>

class OrdersController < ApplicationController
  # ...
  def update
    @order = Order.find(params[:id])
    if @order.update(order_params)
      # ..
    else
      # ...
    end
  end

  private
  def order_params
    params.require(:order)
          .permit(:line_items_attributes: [:quantity, :product_id, :_destroy])
  end
end

這只是一種常見的結帳表格，用戶可以在其中更改購物車中的產品數量。 它允許用戶以簡單的舊同步形式一次操作多個記錄。

盡管如此，嵌套屬性可能是 Rails 中被濫用最多的組件之一，並且超出 1 級嵌套的所有內容通常都會陷入可怕的混亂。 它也是一個非常常見的誤解，即它應該用於分配關聯，在大多數情況下，這應該通過添加指向由關聯創建的_id或_ids屬性的選擇或復選框來完成。

如果您使用它只是為了將所有內容整合到單個 controller 中，因為“我不想有太多的課程。哇”，那么是的，它是一個巨大的反模式。

替代方案實際上是使用 AJAX 讓用戶 CRUD 子記錄而無需重新加載頁面。

我會說你的例子不是嵌套屬性的好候選。 這些關聯中的任何一個實際上是由用戶創建的嗎？

Answer 3

在數據建模中，我們有時將內容拆分到不同的表/模型上，並且恕我直言，嵌套模型/嵌套 forms 主要用於嵌套 model 沒有理由在沒有父級的情況下存在，反之亦然。 例如有地址的人：在創建人時，我們需要立即添加他們的地址，因為（例如在送貨情況下）沒有地址的人沒有任何意義。

嵌套 forms，我們可以在其中整體編輯父/子模型，它很受歡迎，並且恕我直言，在某些非常特定的情況下（如上述示例）仍有其優勢/位置。

但在大多數情況下，父級的創建不依賴於子級，我寧願使用 ajax 調用。 我在一個頁面上顯示所有信息，但是當添加一個孩子時，我確保它立即保存並存儲在數據庫中（使用他們自己的 controller -- 例如在訪問父母的顯示頁面時）。

我相信在大多數情況下，默認/標准的巨型表單並不是最好的 UI/UX 解決方案，我相信這應該是構建頁面的主要驅動力。

回到你的例子：這些不應該以一個巨大的形式顯示，沒有人會編輯一個帖子，還有統計數據，對吧？ 收集並顯示統計數據，但希望永遠不會“創建”。 通常一個跟蹤實際網頁瀏覽量，訪問者......