Szyny - Gdzie (katalogi) umieszczać Modele, które nie są aktywne Rekord

Question

Budujemy aplikacje, które mają Modele, które nie są komponentami bazy danych. Jesteśmy ciekawi, co robią inni w społeczności rails, aby rozwiązać ten problem.

Walczymy z tym, gdzie je umieścić.

Jeżeli mamy:

app/models/domain 

lub

app/domain/models 

czy może

app/models # Business Models 
app/models/ar # Active Record Models 

czy może

app/models/domain/ # Business Models 
app/models/domain/ar # Active Record Models 

Po części zmagamy się z tym, jak bliskie są standardom szyn i jak bardzo chcemy stworzyć strukturę, która będzie odpowiednia dla tego, czego potrzebujemy.

Jeśli myślimy obiektów jak obsługa obiektów, możemy mieć

app/models/service-object 

i

app/models/ # For plain active record 

Inna droga, aby przejść w dół nie ma rzeczy wewnątrz aplikacji, na przykład

/service_objects 

zamiast

/app/models/service_objects 

Przypuszczalnie jeśli chcemy dostęp za pośrednictwem aplikacji szyn jesteśmy lepiej korzystania z aplikacji/w celu skorzystania z konwencji nad konfiguracją.

Answer 1

Z mojego doświadczenia wynika, że ​​podział tych modeli sprowadza się do tego, co funkcjonalnie reprezentują w konkretnym kontekście aplikacji.

Zazwyczaj rezerwuję app/models dla modeli opartych na zasobach. Jeśli ten model reprezentuje zasób, który jest instancjonowany i manipulowany przez aplikację, jest tutaj. Nie musi być AR lub db wspierane.

Jeśli model obsługuje spójną funkcjonalność, ale różni się w zależności od parametrów, nadaję im najwyższy poziom w aplikacji. Takich jak app/mailersapp/observers itp. Jednakże, jeśli masz jeden zasób wymagający obserwatora, może nie mieć sensu posiadanie katalogu app/observers z jednym tylko plikiem.

Wszystko inne przechodzi w lib. Jest kilka powodów, dla których jest to lepsze.

1. Możesz wybrać, kiedy pliki będą wymagać w lib. Możesz znacznie bardziej selektywnie decydować, które pliki zostaną załadowane po uruchomieniu aplikacji. Jeśli umieścisz wszystko w app/models, nie masz ziarnistości nad tym, co zostanie załadowane.

2. Namespacing your models as app coraz łatwiej jest w lib. Oczywiście, możesz nazwać przestrzeń w app/models, ale kilka warstw gniazdowania w app/models zawsze kończy się nieprzyjemnym. Najlepiej jest zachować przestrzeń nazw w numerze lib.

3. Sprzątanie jest o wiele łatwiejsze, gdy masz rzeczy w ich funkcjonalnie poprawnym miejscu. To nie jest zasób? To nie jest obserwator? Musi być w lib. Cały powód, dla którego zastanawiasz się nad tym, to zapewnienie wykrywalności deweloperom.

Answer 2

W przypadku obiektów usługowych zazwyczaj można je znaleźć bezpośrednio w katalogu aplikacji app/services/. Robotnicy i serializatory również podążają za tym wzorem: app/workers/app/serializers/. Jeśli chodzi o modele, które nie są AR, nadal możesz trzymać je w katalogu modeli. To tylko moje podejście do tego.

Answer 3

Jeśli masz klasy, które nie są modelami, na przykład mogą one reprezentować formularz, chciałbym powiedzieć, aby je umieścić w lib.

Jeśli są one ortogonalne dla twojej aplikacji, tzn .: jest to jakiś interfejs używany do wywoływania innej aplikacji, możesz go zawinąć jako prywatny lub publiczny klejnot w zależności od jego zastosowania do reszty społeczności.

W końcu tak naprawdę nie ma to znaczenia. Wybierz jedną rzecz i uzgodnij ją z resztą zespołu. Przenoszenie elementów powinno być łatwe, szczególnie jeśli dodasz cokolwiek zdecydujesz o użyciu do ścieżki ładowania dla aplikacji ($LOAD_PATH += '...').

Answer 4

Jeśli są to modele, należy je umieścić w app/models, ponieważ katalog ten jest przeznaczony dla modeli, a nie tylko dla podklas ActiveRecord.