我对rails比较陌生，最终找到了正确的使用accepts_nested_attributes_for的方法。
然而，网络上有一些严肃的资源说，使用accepts_nested_attributes_for通常是一种不好的做法（比如这个one）。
要避免accepts_nested_attributes_for需要做哪些更改，以及将附加类文件放在哪个文件夹中（我想需要一个附加类）。
我读到virtus适合这个。对吗？
下面是一个仍然使用accepts_nested_attributes_for的非常基本的示例（查找完整的示例here）：
模型
class Person < ActiveRecord::Base
has_many :phones
accepts_nested_attributes_for :phones
end
class Phone < ActiveRecord::Base
belongs_to :person
end
控制器
class PeopleController < ApplicationController
def new
@person = Person.new
@person.phones.new
end
def create
@person = Person.new(person_params)
@person.save
redirect_to people_path
end
def index
@people = Person.all
end
private
def person_params
params.require(:person).permit(:name, phones_attributes: [ :id, :number ])
end
end
视图（people/new.html.erb）
<%= form_for @person, do |f| %>
<p>
<%= f.label :name %><br />
<%= f.text_field :name %>
</p>
<%= f.fields_for :phones do |builder| %>
<p>
<%= builder.label :number %><br />
<%= builder.text_field :number %>
</p>
<% end %>
<%= f.submit %>
<% end %>
[编辑]
使用服务对象是个好主意吗？
最佳答案
您的问题意味着您认为接受嵌套属性功能是一件坏事，但事实并非如此，而且工作得非常好。
我首先要说的是，您不需要其他选择来接受嵌套属性，但我将在本文的末尾介绍这一点。
关于你提供的链接，它没有提到为什么海报认为接受嵌套的属性应该被弃用，而仅仅是声明
依我看，应该不赞成
当考虑如何以单一形式捕获与父级相关的多个记录时，嵌套属性是一个非常重要的概念，这不仅仅是ruby on rails的事情，而且在大多数复杂的web应用程序中，无论用于开发网站的语言。
我一点也不批评你所指的那篇文章。对我来说，这只是指出了用大量不一定与业务逻辑相关的代码填充数据库支持模型的明显替代方法。使用的特定示例只是一个编码样式首选项替代项。
当时间就是金钱，压力很大，一行代码就能完成任务，而示例中显示的22行代码，在大多数情况下（不是所有情况下），我的偏好是在模型中使用一行代码（接受嵌套属性）来接受从表单发回的嵌套属性。
要正确地回答您的问题是不可能的，因为您实际上没有说明为什么您认为接受嵌套属性不是一个好的实践，但是最简单的方法是在控制器操作中提取params散列属性，并在交易。
更新-评论跟进
我认为相关文章的作者认为
面向对象的范例，每个对象应该只读写自己的数据。
使用accepts_nested_attributes_for，一个对象会更改一些
其他对象数据。
好吧，让我们澄清一下。
首先，面向对象的范式并不意味着这样的事情。类应该谨慎，但允许它们与其他类交互。事实上，如果是这样的话，那么ruby中的oo方法就没有意义了，因为ruby中的所有东西都是一个类，因此没有任何东西能够与其他任何东西进行对话。试想一下，如果一个恰好是控制器实例的对象无法与模型或其他控制器交互，会发生什么？
使用accepts_nested_attributes_for，一个对象会更改一些
其他对象数据。
这是一个复杂的陈述，我会尽量简短。
1）模型实例保护数据。在非常复杂的场景中，涉及任何/大多数其他语言（c、delphi、vb等等）中的数百个表，三层解决方案中的中间层就可以做到这一点。用rails的术语来说，模型是业务逻辑的场所，在一个通常由rdbms中的存储过程和视图备份的3层解决方案中，它负责中间层的工作。模特们应该能够很恰当地相互交谈。
2）接受嵌套属性根本不违反任何oo原则。它只是简化了如果方法不存在（正如您正在发现的那样）您需要编写的代码量。如果您接受嵌套在子模型params散列中的属性，那么您所做的一切就是允许子模型以与您的控制器操作相同的方式处理该数据。没有业务逻辑被忽略，您将获得额外的好处。
最后
我能负担得起代码的优雅（比时间更重要）
我可以向您保证，编写20多行代码，并从gem中添加数百行代码，其中一行代码将为您完成工作，这并不是什么优雅的事情。正如其他人（包括我）所说，接受嵌套的属性并不总是一个合适的activerecord方法来使用，通过观察不同的方法来做是一件好事，因为最终您将能够对何时使用内置的做出更明智的判断方法和何时编写自己的。不过，我建议您最好编写自己的代码来处理表单对象并接受嵌套的属性选项，这样才能完全理解正在发生的事情（如您所说，您有时间）。这样你会发现自己理解得更多。
希望这有意义，祝你学习顺利。
更新2
为了最终达到您的观点，并参考您自己的答案，再加上考虑到其他人对您自己的答案所做的出色评论，virtus gem支持的对象是一个非常合理的解决方案，特别是在处理必须收集数据的方式时。这种组合有助于将用户界面逻辑与业务逻辑分开，只要最终将数据传递给模型，这样业务逻辑就不会被忽略（正如您所展示的那样），那么您就有了一个很好的解决方案。
只是不要排除接受嵌套属性的可能性。
你也可以从瑞安·贝茨在表单对象上的railscasts中获得一些好处。
关于ruby-on-rails - accepts_nested_attributes_for的替代方法-也许是virtus，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17634661/