2010-08-25 16 views

Odpowiedz

3

Na podstawie komentarzy do odpowiedzi Toby'ego wydaje się, że chciałbyś mieć aplikacje MVC używane jako komponent w nowej aplikacji. Rails Engines (patrz http://rails-engines.org) zapewnia tę funkcję. Wystarczy zainstalować gem gem i umieścić aplikacje w dostawcy/wtyczkach, a jego moduły/widoki/kontroler są dostępne.

To naprawdę nie jest zgodne z HMVC, w którym kontrolerzy w nowej aplikacji delegują do innych kontrolerów. Ale tak jak Toby, nie widzę tej przewagi.

Co jest ładne o podejściu Engines jest to, że można się jeździć każdy z modeli w wtyczki po prostu dodając wersję modelu do folderu nowe aplikacje app/modelu (to samo odnosi się do widoków i kontrolerów)

Mam nadpisaną aplikację/widoki/układy, aby nadać mojej aplikacji/wtyczce uwierzytelnienia taki sam wygląd jak aplikacja, w której jest ona zawarta.

Dla Rails 3 Railtie zajmuje miejsce silników i jest oficjalnie obsługiwany (i faktycznie używany - Action Mailer jest wtyczką Railtie, ale jeszcze jej nie używałem:

Chec k go na http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html

A nice napisać na to również tutaj http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/

+0

Jakie są różnice/zalety korzystania z wtyczek Railties over Rails? –

+0

Uzasadnienie dla Railtie można znaleźć tutaj http://www.engineyard.com/blog/2010/rails-and-merb-merge-rails-core-part-4-of-6/ – Will

+0

Z witryny Railtie "Developing Rozszerzenie Rails nie wymaga implementacji Railtie, ale jeśli potrzebujesz interakcji ze środowiskiem Rails podczas lub po bootowaniu, to Railtie jest tym, co musisz zrobić w tej interakcji. " – Will

2

Rails ma wtyczki przez długi czas.

Wątpię, aby istniał techniczny powód, dla którego kontroler nie mógł wysłać do innego kontrolera, przekazując obiekt żądania wzdłuż łańcucha. Po prostu nie wiem, co zyskujesz - diagram wygląda jak spaghetti.

Dla mnie jest to niewłaściwe użycie MVC. Sugerowałbym, że jest to znacznie prostsze i łatwiejsze do przeniesienia logiki do modeli i klas niższego poziomu i stworzenia pojedynczego kontrolera, który jest frontem tej logiki, zamiast tworzenia łańcucha kontrolerów.

+0

ja nie zgadzam tutaj. Może dodam kilka nowych funkcji, które mogą być samodzielne ... dobrze jest mieć to jako samodzielny komponent MVC, zamiast włączać wszystko do głównej aplikacji MVC, dzięki czemu można go ponownie wykorzystać w innych projektach. Ponadto każdy z tych komponentów MVC, które widzisz na diagramie, może pochodzić od zewnętrznego dostawcy. Nie mieszałbym ich w mojej głównej aplikacji MVC.Schemat nie wydaje mi się spaghetti, wydaje się być bardzo dobrze zorganizowany. Delegat zamiast rzucać wszystko w jedną dużą porcję, która będzie coraz większa. –

+0

Myślę, że to nieszczelna abstrakcja. Jakie są korzyści wynikające z tego, że dobrze zorganizowana warstwa obiektów obsługująca logikę biznesową nie może osiągnąć bardziej szczegółowej i łatwo sprawdzonej mody? –

+0

A głosowanie mnie, ponieważ mam poważne i przemyślane zastrzeżenia dotyczące stylu architektonicznego, jest trochę surowe. –

1

W poście na blogu Rails 3 DHH wspomniał o projekcie the Cells. Nie użyłem tego, ale mam zamiar to sprawdzić.

Przykładowy koszyk pokazuje, w jaki sposób tego rodzaju funkcjonalność może oczyścić kod aplikacji. Kod pobierający dane powinien zostać umieszczony w sterowniku. W każdej akcji lub w poprzednim filtrze. Komórka wydaje się znacznie lepszym rozwiązaniem.