Rails: PolyMorphic или STI или что-то еще для управления пользователями?

Я не думаю, что есть простое объяснение тому, почему любой подход является лучшим в любых обстоятельствах. Значительное количество вопросов по Stack Overflow - это вопрос о том, как проектировать отношения между их моделями. Это сложная тема, и правильные решения требуют глубокого знания проблемы, которую вы решаете. И даже тогда вы, вероятно, не поймете это правильно первые пару раз.

На данный момент лучший способ - полностью проработать TDD / BDD в этом вопросе и позволить тестам / спецификациям вытеснить ваш дизайн. И не бойтесь рефакторинга, если найдете лучший способ. В большинстве случаев вы увидите правильное решение только после того, как попробуете пару неправильных. Вы познакомитесь с крайними случаями. Как выразился Уорд Каннингем в своей аналогии с «Техническим долгом»: «Рефакторинг впоследствии, как если бы вы знали, что делаете с самого начала». Не забудьте пройти приемочные испытания, чтобы потом проверить его поведение.

Более конкретно о вашей проблеме. Есть третий вариант - полностью разделить классы, каждый со своей таблицей. Я пробовал это в своем текущем проекте, и он мне нравится. Вам не нужно определять что-то вроде пользователя, если это не имеет смысла в вашей сфере деятельности. Если у них общее поведение, используйте миксины. Самая важная оговорка заключается в том, что теперь уже непросто заставить их входить в систему через ту же форму.

У меня есть модели администратора, рекрутера, поставщика и посетителя. Все они являются отдельными моделями, разделяющими некоторое поведение с миксинами. У всех есть свои собственные контроллеры с именами, с которыми нужно работать. Например, все действия для администраторов находятся в пространстве имен Backend. Также существует ApplicationController с пространством имен. Backend :: ApplicationController просто указывает before_filter :authorize_admin!. Никаких переключений, никаких сложных case-операторов, ничего.

Особое внимание нужно уделять условностям. Если вы используете одни и те же имена во всех моделях, ваши миксины могут стать очень простыми. Прочтите ActiveSupport :: Concern, чтобы упростить работу с миксинами. У меня такой миксин:

module Account
  extend ActiveSupport::Concern
  included do
    devise :database_authenticatable, :trackable, :recoverable, :rememberable
  end
end

И в моих маршрутах:

devise_for :recruiters
devise_for :suppliers
# etc...

И app/controllers/backend/application_controller.rb выглядит так:

class Backend::ApplicationController < ::ApplicationController
  layout "backend"
  before_filter :authenticate_admin!
  def current_ability
    @current_ability ||= AdminAbility.new(current_admin)
  end
end

Итак, в заключение. Подойдет любая архитектура. STI и полиморфизм имеют свое место, но не забудьте смоделировать свою архитектуру в соответствии с вашей областью. Ruby - очень гибкий язык, и вы можете использовать это в своих интересах. Devise и CanCan - отличные жемчужины, с легкостью справляющиеся с подобными ситуациями. Я показал вам свое решение для проекта, над которым сейчас работаю. Мне он подходит, но я не могу сказать, подходит ли он вам. Не бойтесь экспериментировать и проводить рефакторинг, когда чувствуете, что приняли неправильное решение, вместо того, чтобы продолжать исправлять свою первоначальную идею.

PS. Кстати об ИППП и отношениях: они тоже отлично работают вместе. Вы можете определять отношения от одного подкласса к другому подклассу. Все будет работать как положено.

Может возникнуть соблазн переоценить это, но я не уверен, что то, что вы хотите сделать, очень сложно.

STI, вероятно, здесь не лучшая идея, потому что вы ограничиваете пользователя не более чем одной из этих ключевых ролей.

Что касается хранения информации о членстве, я не уверен, что ваши таблицы будут «огромными», когда вы добавите столбцы для STI. Если они равны нулю, они на самом деле не потребляют никаких ресурсов. Если вам не нужно выбирать эти данные, вы можете подумать о том, чтобы создать один столбец role_information, а затем использовать serialize :role_information, чтобы вы могли определить хеш и сохранить его в столбце.

Другой вариант - переопределить методы таким образом, чтобы они проверяли принадлежность к роли при ответе, то есть:

has_many :agents
def agents
  return nil unless self.has_role(:manager) 
  return self[:agents]
end

Замените has_role на то, что вам нужно для проверки членства в роли.

Вы также можете сделать это на стороне настройки.

Авторизация для определенных функций должна выполняться в вашем контроллере, поэтому вам следует проверить членство в роли на этом этапе.