Czy ktoś tutaj używa DTO do przesyłania danych z kontrolera do widoku? Jeśli tak, to gdzie zaleca się przechowywanie tych plików?/apps/dtos, a następnie pozwolić im odzwierciedlić strukturę widoku? Wszelkie zalecenia dotyczące testowania tych zwierząt za pomocą rspec?Ruby on Rails dto objects - Gdzie je przechowujesz?
Konwencja Rails nie używa warstw rozproszonych dla kontrolerów i warstw widoku. Oddzielenie istnieje, ale jest logiczne i stosunkowo cienkie/lekkie w porównaniu z typami frameworków, które widzisz na ziemi Javy.
Podstawową architekturą jest to, że kontroler ustawia zmienne instancji, które są dostępne w odpowiednim widoku. W ogólnym przypadku zmiennymi instancji będą instancje modelu lub kolekcje instancji modelu (pochodzące z bazy danych). Modele powinny stanowić rdzeń logiki biznesowej. Kontrolery koordynują przepływy danych. Widoki go wyświetlają. Pomocniki są używane do formatowania wyświetlanych wartości w widoku ... wszystko, co pobiera wartość modelu i robi coś tylko w celu wyświetlania (może się okazać, że metoda pomocnicza używana wielokrotnie może być w rzeczywistości lepsza dla samego modelu).
Jeśli jednak widok wymaga znajomości wielu różnych modeli, łatwiej jest zawrzeć modele w innym obiekcie na wyższym poziomie abstrakcji. Nic nie stoi na przeszkodzie, aby tworzyć obiekty z nieaktywnym rekordem, które zbierają i koordynują rzeczywiste modele AR. Następnie można utworzyć instancje tych obiektów w kontrolerze i udostępnić je w widoku. Zwykle musisz mieć dość złożony poziom złożoności w kontrolerze, aby potrzebować tego typu rzeczy.
Byłbym skłonny do rzucania takich obiektów do aplikacji/modeli - Railsy już ładują wszystko w tym katalogu, utrzymują rzeczy łatwe z punktu widzenia konfiguracji/oczekiwań.
Jeśli pochodzisz z tła .NET lub J2EE, możesz myśleć o wzorach takich jak DTO. Możesz lub nie być zaskoczonym (i być może szczęśliwym), aby dowiedzieć się, że Rails nie robi tego w sposób konwencjonalny.
W szczególności nie ma potrzeby formalnego przesyłania (lub przechowywania) serializowanych obiektów między kontrolerami i widokami. Zmienne instancji (zazwyczaj wartości atrybutów modelu) utworzone w kontrolerze są dostępne w widoku za darmo, zgodnie z ramami, bez konieczności dodatkowego wysiłku programistycznego.
To, co mi powiedziano, to ogólnie to, że praca jest wykonywana przez "pomocników". Zasadniczo pomagają one w formatowaniu obiektów modelu w celu wykorzystania ich w widoku. Więc zdecydowanie nie jest mapowaniem pojęć 1-1, ale to jest myślenie w świecie szyn
Proszę nie słuchać innych odpowiedzi. Są okropne. Pomocnicy Railsów są okropni. Używanie modeli szyn wszędzie jest okropne. Błagam Cię, zaprojektuj poprawnie swoją aplikację i zdecyduj, czy potrzebujesz DTO, czy nie. Zdecyduj, czy chcesz mieć modele szyn, aby obsługiwały rzeczy inne niż komunikacja z bazą danych. Zdecyduj, czy rzeczywiście nie chcesz mieć warstwy pomiędzy aplikacją i szynami itd. Projekt Railsów jest odpowiedni tylko dla małych aplikacji lub aplikacji, które trzeba bardzo szybko opracować. Ale jeśli nie jest to coś trywialnego i spodziewasz się go rozwijać przez jakiś czas, zainwestuj swój czas w odpowiedni projekt. Nie bój się łamać udogodnień Rails. I niech siła z tobą.
Dzięki Toby. Przyzwyczaicie się do tego trochę, ale ja raczej widzę myślenie. Doceniam dobrze sformułowaną odpowiedź. –