Come organizzare le azioni che non rientrano nel normale MVC

Question

Sto creando un'applicazione di sondaggio, quindi ho creato un controllore di sondaggi che si comporta in modo molto riposante durante la creazione, l'aggiornamento e così via. Tuttavia ora sto aggiungendo altre azioni come "prendere", prendere un sondaggio e "condividere", per condividere un sondaggio. Ci sono anche altre azioni. Sto iniziando a chiedermi se dovrei organizzare il mio codice in modo diverso e spostare quelle nuove azioni nei loro controller, ma non sono così sicuro di prendere o condividere o alcune delle mie altre azioni che si adattano davvero bene a REST. Hanno quasi più senso come azioni se non fossi un po 'preoccupato per le dimensioni del controller del sondaggio.

O avrei potuto lasciarlo così com'è o stavo pensando di creare uno spazio dei nomi di sondaggio e creare come Survey :: TakeController e Survey :: ShareController. Allora suppongo che userò la nuova azione o indice?

Non sono esattamente sicuro del modo corretto di farlo. Se creo uno spazio dei nomi di sondaggio dovrei spostare l'originale SurveyController in esso? Ciò renderebbe alcuni metodi bizzarri come survey_survey_path.

Answer 1

Per pensare RESTfully, dovresti probabilmente smettere di considerarli come "controllori con azioni" e iniziare a pensarli come "oggetti che possono essere creati/aggiornati, ecc" - i controllori sono solo proxy per le viste che mostrano i risultati di creare/aggiornare un oggetto.

Un sacco di tempo, ho scoperto che un'azione extra è in realtà solo una variazione di "aggiornamento" - solo con i propri requisiti speciali (ad esempio solo alcune persone possono aggiornarlo o qualsiasi altra cosa). Questo tipo di logica può spesso andare all'interno del modello stesso (ad es. "MyModel # can_be_edited_by? (Some_user)").

A volte si scopre che in realtà si dispone di un modello aggiuntivo "nascosto" che richiede una propria interfaccia RESTful.

Ad esempio con il tuo "prendere" un sondaggio - Sto indovinando, ma quello che hai è qualcosa come un "SurveyResult" e una persona può "creare" sondaggi "ma quando" prendono "un sondaggio, in realtà sono la creazione di un "SurveyResult" (l'altro commentor chiamato questo un "SurveyParticipation" - ma è la stessa cosa)

la cosa è che si avrà probabilmente più SurveyResults che ogni belong_to:. indagine e belong_to: some_user_model

.

Quindi puoi impostare dei bei percorsi riposanti come: /surveys/123-my_favourite_colour/results

che restituirà un insieme di tutti i risultati per un singolo sondaggio

Questo è in realtà il modo RESTful per visualizzare questa parte del proprio spazio oggetto.

Come condividere un sondaggio - questa è una domanda più interessante. Dipende da come hai impostato la tua autorizzazione per "condividere". Dipende anche da cosa intendi per "condividere". Stai condividendo i risultati di un sondaggio, o condividendo l'oggetto sondaggio stesso (in modo che un altro utente possa modificare le domande) o sei (come una persona che ha appena preso parte a un sondaggio) che condivide un link al sondaggio in modo che i tuoi amici possono anche fare il sondaggio?

Per i primi due precedenti, prenderei in considerazione una classe "SurveyPermission" che appartiene a: survey e belongs_to: some_user_model. Puoi creare una SurveyPermission per un altro utente - e Surveys può essere modificato dal creatore o chiunque abbia il permesso di modificarlo. Quindi l'azione di condivisione consiste nel creare una SurveyPermission. Anche se per essere onesti, è probabile che la tua SurveyPermission sia utilizzata solo per creare ed eliminare, quindi potrebbe essere più semplice attaccare queste due azioni nel controller Survey.

Per questi ultimi - beh, questo è solo l'invio di un link a qualcuno "create_survey_result (@survey)" ...

Aggiornamento:

Io in genere non si preoccupano gli spazi dei nomi a meno che non ci sono due risorse ha chiamato la stessa cosa (ma in contesti diversi). Hai solo bisogno di spazi dei nomi per disambiguare tra loro e che non sembra essere il caso qui.

In questo caso - l'unica namespacing che si verifica è nel percorso:

map.resources :surveys do |s| 
    s.resources :results 
    s.resources :shares # ??? 
end 

dà tali rotte come:

new_survey_path 
surveys_path 
new_survey_result_path(@survey) 
survey_results_path(@survey) 

Answer 2

Se si vuole rimanere con l'approccio RESTful, allora si potrebbe avere una risorsa SurveyParticipation, con i new/create azioni che è invocata quando qualcuno prende un sondaggio. E a, ahem, SurveyShare risorsa per condividere un sondaggio. Quel nome è piuttosto imbarazzante!

Personalmente non penso che sia la fine del mondo se devi aumentare i tuoi controllori esistenti con un piccolo numero di azioni aggiuntive, a patto che non sfugga di mano. RESTful Rails ci ha salvato dai brutti giorni in cui i controller avevano decine di azioni.