Jak organizować akcje, które nie pasują do normalnego MVC

Question

Tworzę aplikację ankietową, więc utworzyłem kontroler ankiet, który zachowuje się bardzo spokojnie tworząc, aktualizując itp. Ankietę. Jednak teraz dodam do niego inne działania, takie jak "weź", za wypełnienie ankiety i "udostępnij", aby udostępnić ankietę. Jest też więcej akcji. Zaczynam się zastanawiać, czy nie powinienem inaczej organizować mojego kodu i przenosić te nowe działania do ich własnych kontrolerów, ale nie jestem pewien czy coś takiego zabrać lub podzielić się, czy też niektóre z moich innych działań naprawdę dobrze pasują do RESTU. Są prawie sensowne jako akcje, jeśli nie martwi mnie trochę wielkość kontrolera.

Albo mógłbym zostawić to tak, jak jest, albo myślałem o stworzeniu przestrzeni nazw ankiet i tworzeniu takich jak Ankieta :: TakeController i Ankieta :: ShareController. Czy mógłbym wtedy użyć nowej akcji lub indeksu?

Nie jestem do końca pewien, czy jest to właściwy sposób. Jeśli utworzę obszar nazw ankiety, czy powinienem przenieść w tym miejscu oryginalny SurveyController? To spowodowałoby, że niektóre dziwnie wyglądające metody, takie jak survey_survey_path.

Answer 1

Aby myśleć RESTfully, powinieneś przestać myśleć o nich jako o "kontrolerach z akcjami" i zacząć myśleć o nich jako o "obiektach, które można tworzyć/aktualizować itp." - kontrolerzy są po prostu proxy dla widoków, które pokazują wyniki tworzenie/aktualizowanie obiektu.

Wiele razy odkryłem, że dodatkowa czynność jest tak naprawdę odmianą "aktualizacji" - tylko z własnymi specjalnymi wymaganiami (np. Tylko niektóre osoby mogą ją zaktualizować lub cokolwiek innego). Ten rodzaj logiki często może wejść do samego modelu (np. "MyModel # can_be_edited_by? (Some_user)").

Czasami okazuje się, że faktycznie masz dodatkowy "ukryty" model, który wymaga własnego interfejsu RESTful.

Np. Z twoją ankietą "bierz" - zgaduję, ale to, co masz, jest czymś w rodzaju "Ankiety", a osoba może "stworzyć" ankietę ", ale kiedy" wezmą "ankietę, faktycznie tworząc „SurveyResult” (drugi commentor nazwie to „SurveyParticipation” - ale to samo)

rzeczą jest, że prawdopodobnie będziesz mieć wiele SurveyResults że każdy belong_to. Badanie i belong_to: some_user_model

.

Następnie możesz skonfigurować ładne, spokojne trasy, takie jak: /surveyys/123-my_favourite_colour/results

, który zwróci zestaw wszystkich wyników dla pojedynczego badania

To jest rzeczywiście RESTful sposób, aby wyświetlić tę część swojej przestrzeni obiektowej.

Co do udostępnienia ankiety - to ciekawsze pytanie. To zależy od tego, jak masz ustawioną autoryzację do "udostępniania". Zależy to również od tego, co masz na myśli przez "udział". Czy udostępniasz wyniki ankiety lub udostępniasz sam obiekt ankiety (aby inny użytkownik mógł edytować pytania) lub jesteś (jako osoba, która właśnie wzięła udział w ankiecie) udostępniając link do ankiety, aby Twoi znajomi mogą również wziąć udział w ankiecie?

Dla pierwszych dwóch powyższych - rozważałbym klasę "SurveyPermission", która należy do: survey i belongs_to: some_user_model. Możesz utworzyć SurveyPermission dla innego użytkownika - ankiety mogą być edytowane przez twórcę lub każdego, kto ma uprawnienia do edycji. Tak więc akcja udostępniania polega na utworzeniu ankiety SurveyPermission. Jednak, szczerze mówiąc, twoja ankieta SurveyPermission będzie prawdopodobnie używana tylko do tworzenia i usuwania, więc łatwiej będzie trzymać te dwie akcje w kontrolerze Survey.

W tym ostatnim przypadku - dobrze, że po prostu wysyłając link do kogoś się „create_survey_result (@survey)” ...

Aktualizacja:

ja generalnie nie przeszkadza z przestrzeniami nazw, chyba że istnieją dwa zasoby o nazwie to samo (ale w różnych kontekstach). Potrzebne są tylko przestrzenie nazw, aby je rozróżnić, co nie ma miejsca w tym przypadku.

W tym przypadku - tylko Przestrzenie nazw, które występuje w routingu:

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

daje takich trasach jak:

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

Answer 2

Jeśli chcesz pozostać przy podejściu RESTOWN, możesz mieć zasób SurveyParticipation, przy czym akcje będą wywoływane, gdy ktoś wykona ankietę. A, ahem, SurveyShare źródło udostępnienia ankiety. To imię jest dość niezręczne!

Osobiście nie uważam, że to koniec świata, jeśli trzeba uzupełnić istniejących kontrolerów o niewielką liczbę dodatkowych działań, o ile nie wymknie się spod kontroli. RESTful Rails uratował nas od złych dawnych czasów, gdy kontrolerzy mieli dziesiątki akcji.