Cómo organizar acciones que no encajan en el MVC normal

Question

Estoy creando una aplicación de encuesta, así que creé un controlador de encuestas que se comporta de manera muy tranquila creando, actualizando, etc. una Encuesta. Sin embargo, ahora estoy agregando otras acciones como 'tomar', tomar una encuesta y 'compartir', para compartir una encuesta. También hay más acciones. Estoy comenzando a preguntarme si debería organizar mi código de manera diferente y mover esas nuevas acciones a sus propios controladores, sin embargo, no estoy tan seguro de tomar o compartir, o algunas de mis otras acciones realmente encajan en REST. Casi tienen más sentido como acciones si no estoy un poco preocupado por el tamaño del controlador de la encuesta.

O podría dejarlo tal como está o si estaba pensando en crear un espacio de nombre de encuesta y crear como Survey :: TakeController y Survey :: ShareController. Entonces, ¿entonces supongo que usaría la nueva acción o índice?

No estoy exactamente seguro de la forma correcta de hacerlo. Si creo un espacio de nombre de encuesta ¿debo mover el SurveyController original en él? Eso haría que algunos métodos de aspecto extraño como survey_survey_path.

Answer 1

Pensar RESTfully, probablemente deberías dejar de pensar en ellos como "controladores con acciones" y empezar a pensar en ellos como "objetos que se pueden crear/actualizar, etc." - los controladores son solo aproximaciones para las vistas que muestran los resultados de creando/actualizando un objeto.

Muchas veces, he encontrado que una acción adicional es solo una variación de "actualización", solo con sus propios requisitos especiales (por ejemplo, solo algunas personas pueden actualizarla o lo que sea). Ese tipo de lógica a menudo puede ir dentro del propio modelo (por ejemplo, "MyModel # can_be_edited_by? (Some_user)").

A veces se encuentra con que realmente tiene un modelo "oculto" adicional que necesita su propia interfaz RESTful.

Por ejemplo, con su "tomar" una encuesta, supongo, pero lo que tiene es algo así como un "SurveyResult" y una persona puede "crear" una encuesta "pero cuando" toman "una encuesta, en realidad son la creación de un "SurveyResult" (el otro commentor llama a esto una "SurveyParticipation" - pero es la misma cosa)

la cosa es que es probable que tenga múltiples SurveyResults que cada belong_to:. encuesta y belong_to: some_user_model

.

Luego puede configurar buenas rutas de descanso tales como: /surveys/123-my_favourite_colour/results

que devolverá un conjunto de todos los resultados para una sola encuesta

Esta es la forma RESTful de ver esta parte de su espacio de objetos.

En cuanto a compartir una encuesta, esa es una pregunta más interesante. Depende de cómo haya configurado su autorización para "compartir". También depende de lo que quiere decir con "compartir". ¿Está compartiendo los resultados de una encuesta, o compartiendo el objeto de la encuesta en sí (para que otro usuario pueda editar las preguntas) o usted (como una persona que acaba de participar en una encuesta) comparte un enlace a la encuesta para que tus amigos también pueden tomar la encuesta?

Para los dos primeros anteriores, consideraría una clase "SurveyPermission" que pertenece a: survey y belongs_to: some_user_model. Puede crear una SurveyPermission para otro usuario, y las encuestas pueden ser editadas por el creador o cualquier persona que tenga permiso para editarla. Por lo tanto, la acción compartida es crear una SurveyPermission. Aunque, para ser honesto, es probable que SurveyPermission solo se use para crear y eliminar, por lo que puede ser más simple pegar esas dos acciones en el controlador Survey.

En este último caso - bueno, eso es sólo el envío de un "create_survey_result (@survey)" enlace a alguien ...

Actualización:

No me molesto en general, con espacios de nombres menos hay dos recursos nombrado lo mismo (pero en diferentes contextos). Solo necesita espacios de nombres para desambiguar entre ellos y ese no parece ser el caso aquí.

En este caso - el único espacios de nombre que se da es en el enrutamiento:

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

da esas rutas como:

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

Answer 2

Si desea seguir con el enfoque RESTful, puede tener un recurso SurveyParticipation, con las acciones new/create que se invocan cuando alguien realiza una encuesta. Y a, ejem, SurveyShare recurso para compartir una encuesta. ¡Aunque ese nombre es bastante incómodo!

Personalmente, no creo que sea el fin del mundo si tiene que aumentar sus controladores existentes con un pequeño número de acciones adicionales, siempre que no se salgan de control. RESTful Rails nos salvó de los malos viejos tiempos cuando los controladores tenían decenas de acciones.