Когда можно не следовать соглашению о множественном числе моделей

Question

Я хотел бы знать, когда можно не следовать соглашению о множественном числе моделей.

У меня есть две модели:

class Post < ApplicationRecord
  belongs_to :site
  has_many :metrics, class_name: 'Metrics', dependent: :delete_all
end

class Metrics < ApplicationRecord
  belongs_to :post
end

Я создал другой вопрос что другие пользователи SO сказали, что неправильно иметь множественные имена моделей, но в случае Metrics было бы очень странно называть это Metric. Я хотел бы понять соглашение вокруг этого - нормально ли жертвовать соглашением ради читабельности?

Answer 1

Что TedTran2019 сказал.

Не зная ничего о вашем домене, я бы испытал соблазн иметь модель PostMetric что-то вроде:

# == Schema Information
#
# Table name: post_metrics
#
#  id                     :bigint           not null, primary key
#  post_id                :integer          not null
#  metric_id              :ingeger          not null
#  value                  :string           not null
#  created_at             :datetime         not null
#  updated_at             :datetime         not null
#
class PostMetric < ApplicationRecord
  belongs_to :post
  belongs_to :metric
end

... иPost модель что-то вроде:

class Post < ApplicationRecord
  belongs_to :site
  has_many :post_metrics, dependent: :destroy
  has_many :metrics, through: :post_metrics

  Metric.all.pluck(:name).each do |metric_name|
    define_method("#{metric_name}_metric") do 
      metrics.where(name: metric_name)
    end
    define_method("post_#{metric_name}_metric") do 
      post_metrics.where(metric: send("#{metric_name}_metric"))
    end
  end

end

... и модель Metric что-то вроде:

# == Schema Information
#
# Table name: metrics
#
#  id                     :bigint           not null, primary key
#  name                   :string          not null
#  created_at             :datetime         not null
#  updated_at             :datetime         not null
#
class Metric < ApplicationRecord
  has_many :post_metrics
  has_many :posts, through: :post_metrics
end

Естественно, вам нужно будет seed (или иным образом создать) каждая из ваших Metric записей.

Таким образом, ваша Post отвечает на metrics, а Metric - не сверхъестественное имя модели.

Кроме того, выВы сможете сделать что-то вроде @post.view_metric и @post.post_view_metric (для извлечения модели соединения, если это будет полезно).

Когда вы удаляете запись Post, она уничтожит все связанные с нейPostMetric присоединяйтесь к моделям, но оставьте свои Metric модели без изменений.

Answer 2

Нет. Вы ВСЕГДА используете единственное имя модели, имя контроллера множественного числа и имена таблиц во множественном числе. Вы никогда не должны нарушать это соглашение.

tl; д-р, это никогда не нормально (Впрочем, это просто личное мнение и то, как меня учили. Я верю, что это также и в руководстве по стилю Rails)

https://github.com/rubocop-hq/rails-style-guide

model Metric
controller MetricsController
table metrics
routes: either resources metrics or resource metric

Заметьте, как даже с единичным ресурсом контроллер все еще множественный?

https://gist.github.com/iangreenleaf/b206d09c587e8fc6399e

Подумайте, что бы произошло, если бы у вас было 30 моделей, которые были единичными,затем тот, который был во множественном числе, и как это будет сбивать с толку.

Answer 3

Проверьте руководство https://guides.rubyonrails.org/active_record_basics.html#naming-conventions, вы можете пропустить соглашение, но рельсы предполагают, что вы должны быть осторожны (например, ожидайте, что некоторые вещи будут единственными или множественными, и он автоматически множит или объединяет строки, когдапо умолчанию), вы можете жестко запрограммировать то, что rails пытается определить, но для этого требуется больше кода.

Обратите внимание, что вы спрашиваете о «читабельности». Когда вы привыкаете к соглашениям рельсов, «Метрика» более понятна для чтения, чем «Метрики», поскольку в контексте рельсов она также дает вам гораздо больше информации о названии других вещей.

ОбычноЯ нарушаю соглашения rails для таких вещей, как ключи базы данных или таблицы, если база данных поступила из другой системы, для новых вещей я всегда стараюсь придерживаться соглашений rails, если только нет реального веского аргумента с доказанной выгодой от его использования.

РЕДАКТИРОВАТЬ: есть также некоторые нерегулярные существительные, которые вы также должны использовать осторожно, например, если у вас есть новостной сайт, «новости» могут быть как множественными, так и единственными, поэтому вы можете изменить название модели на NewsArticle, чтобы вы могли иметь «новостная статья "и" новостные статьи "и таблица" news_articles ", например.