Какова лучшая практика для таких маршрутов?

Question

У меня есть модель Job, которая belongs_to для трех пользователей (клиент, сотрудник и qa). Для клиента задано значение current_user при создании задания, но сотрудник и пользователи выбирают свои задания из пула невостребованных заданий.

В настоящее время я реализовал это следующим образом: match 'jobs/:id/assign/:type/:user_id' => 'jobs#assign' с помощью метода assign с оператором case в params[:type]. Так, например, jobs/1/assign/qa/1 назначает пользователя 1 в качестве qa для задания 1.

Это работает, но кажется неаккуратным, и я бы хотел заменить его на что-нибудь более чистое. Существует ли общее соглашение для подобных ситуаций?

Редактировать: Пользователи могут одновременно иметь роли сотрудника и сотрудника. Это то, что заставляет меня чувствовать себя настолько сложным.

class User < ActiveRecord::Base
  has_many :submitted_jobs,  :class_name => 'Job', :foreign_key => 'customer_id'
  has_many :assigned_jobs,   :class_name => 'Job', :foreign_key => 'employee_id'
  has_many :reviewed_jobs,   :class_name => 'Job', :foreign_key => 'qa_id'

class Job < ActiveRecord::Base
  belongs_to :customer, :class_name => 'User', :foreign_key => 'customer_id'
  belongs_to :employee, :class_name => 'User', :foreign_key => 'employee_id'
  belongs_to :qa,       :class_name => 'User', :foreign_key => 'qa_id'

Answer 1

Вы можете рассмотреть более RESTful подход к вашей проблеме. Две вещи, которые RESTful Best Practices называет «ошибками классического новичка», заключаются в «сильном отражении модели данных ActiveRecord для выбора ресурсов» и «добавлении пользовательских методов, если стандартные методы не подходят».

Существительные - новые глаголы

• Измените свой способ объяснения сценария, действия
  • Используйте существительное , чтобы описать действие
  • Существительное, данное вашему сценарию - это ресурс, который вы ищете
• Пользователь подписывается на группу -> A подписка создана
• Проект подтвержден его владельцем -> A Проверка проекта создана
• Пользователь деактивирует свою учетную запись -> A Активация учетной записи пользователя удалена

Вы можете легко создать ресурс "Job Assignment" (, а не обязательно отдельную модель) и, например, create с правильными параметрами. В грубых псевдорельсах:

# routes
resources :job_assignments, :only => [:create, :delete] # or whatever you need

# job_assignments_controller
class JobAssignmentsController < ApplicationController
  def create
    user = User.find(params[:user_id])
    job  = Job.find(params[:job_id])
    user.assign(job, params[:job_type]) # handle model logic
  end

  def destroy
    user = User.find(params[:user_id])
    job  = Job.find(params[:job_id])
    user.unassign(job, params[:job_type]) # handle model logic
  end
end

В презентации есть несколько хороших примеров (начиная со слайда 32).

Answer 2

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

Ваша текущая маршрутизация великолепна, если «Работа» и уполномоченный известны заранее. По моему мнению, если вы заполняете работу И информацию о типе сотрудника на маршруте, вы делаете слишком много.

Сотрудники / QA также входят и выбирают свою работу? Если они это сделают, то их собственная информация будет доступна на стороне сервера в "current_user".

В этом случае в идеале маршрут должен быть "/ job /: id / pick" и перейти к действию "JobsController # pick", например, с запросом POST. В вашем действии контроллера вы получите информацию о пользователе eemployee / qa в current_user.

config/routes.rb

resource :jobs do
  member do
    post :pick
  end
end

in app/controller/jobs_controller.rb

def pick
  job = Job.find(params[:id])
  current_user.jobs << job # User has_many :jobs
  # or
  job.user = current_user
  ...
end

Пожалуйста, дайте мне знать, если сотрудники / qa НЕ входят, и я обновлю решение соответствующим образом с другим решением.