wskazówki, gdzie umieścić klasy w aplikacjach Railsowych, które nie pasują do siebie.

Question

Zastanawiam się, czy istnieją jakieś najlepsze praktyki dotyczące tego, gdzie umieścić niestandardowe pliki Ruby w aplikacjach Railsowych, te, które nie pasują do żadnego z domyślne katalogi (controllers/models itp.).

Mówię o klasach, które są używane przez kontrolery/modele itp., Ale nie są podklasami żadnej z klas bazowych Rails. Klasy zawierające funkcje wyodrębnione z modeli, aby zmniejszyć ich wagę. Niektóre z nich wyglądają jak modele, ale nie są modelami AR, niektóre wyglądają bardziej jak "usługi", niektóre są czymś pośrednim lub czymś innym.

Kilka losowych przykładów:

ćwiczenia

• „strategia”, które obsługują uwierzytelniania hasłem, via facebook itp
• „XParams” obiektów, które hermetyzują parametrów lub obiektów „XCreator”, które zajmują się przetwarzaniem params do wykonać pewne złożone działanie, które powoduje tworzenie niektórych modeli AR w klasach, które wysyłają żądania do zewnętrznych interfejsów API lub zawierają te żądania i odpowiedzi:
• fałszywe modele, które można zastąpić rzeczywistym modelem AR (np. er)
• Resque pracy
• klas przechowywać i odczytywać informacje z Redis
• klas wykonujące pewne konkretne działania, takie jak przetwarzanie danych, generowanie raportów itd. i są nazywane od pracy Resque lub zadań kasę

Mam ich już całkiem sporo, niektóre z nich są dodawane do lib, co kończy się kupą losowych klas i modułów, niektóre wkraczają do app/models. Chciałbym to jakoś zorganizować, ale nie wiem od czego zacząć.

Czy tylko modele AR mają być oznaczone jako app/models? Czy można też umieścić tam dowolne modele domen lub pomocników? Jak decydujesz, czy coś jest modelem?

Czy wszystko, co nie pasuje do app, należy przejść pod lib? A może powinienem dodać kilka nowych niestandardowych podkatalogów do app? Jakie podkatalogi i jak podzielić klasy niestandardowe?

Jak sobie z tym poradzić w swoich projektach? Wiem, że każdy projekt jest nieco inny, ale muszą istnieć pewne podobieństwa.

Answer 1

Dobre pytanie - nie mam konkretnej odpowiedzi dla ciebie

ale polecam sprawdzić ten Opublikuj - http://blog.codeclimate.com/blog/2012/02/07/what-code-goes-in-the-lib-directory/ - należy zapoznać się z wszystkimi komentarzami

na obecnym projekcie mam masę obiektów innych niż ActiveRecord w aplikacji/modelach, działa, ale nie jest idealny Umieszczam kod "nie do użytku" specyficzny dla aplikacji pod lib

inne alternatywy, które wypróbowałem w projektach pobocznych (powiedzmy, że mamy sporo obiektów dowodzenia) szyny jest ból, jeśli chodzi o przestrzenie nazw w ramach aplikacji, ładuje wszystko do góry w tej samej przestrzeni nazw domyślnie

app/ 
    commands/ 
    products/create_command.rb   # Products::CreateCommand 
    products/update_price_command.rb # Products::UpdatePriceCommand 

zastępcę, wszystko oprócz szyn pod src lub katalogu APP_NAME

app/ 
    src/ 
    commands/ 
     create_product.rb   # Commands::CreateProduct 
     update_product_price.rb # Commands::UpdateProductPrice 

I haven W tym celu znajdziesz dobre rozwiązanie, najlepiej drugie, ale byłoby miło nie mieć dodatkowego katalogu pod aplikacją, w ten sposób otworzysz aplikację i zobaczysz kontrolery, polecenia, modele itp.

Answer 2

Umieszczam dowolne klasy modelu (takie jak podklasy STI) w apps/models. Moje pozostałe zajęcia umieszczam w lib, ponieważ wydaje się, że jest to najlepsze miejsce do ich umieszczenia. Łatwo mi wiedzieć, gdzie szukać. Łatwiej też pogrupować moje testy, ponieważ moje zajęcia modelowe są w jednym miejscu.

Zgodnie z konwencją nie cierpię umieszczać lekcji pomocniczych w app/models. Jeśli są to klasy prezenterów, należą do app/helpers. Jeśli tak nie jest, to wydaje się, że to najlepsze miejsce dla nich.

Answer 3

Często moje klasy znajdują się w lib w podkatalogach, w których moduły o tej samej nazwie, co podkatalog, są odpowiedzialne za ich włączenie. (Railsy są bardzo wrażliwe na nazwy plików i nazwy klas, jeśli chodzi o autoloader.)

Inną opcją jest enkapsulacja każdego modułu do jego własnego klejnotu, a następnie odwołanie się do klejnotu za pomocą Gemfile. Pozwala to na dzielenie kodu pomiędzy projektami.

Answer 4

dotknąć na wiele różnych przypadków użycia, i myślę, że ta część jest najbliżej „prawo” odpowiedzi:

Mam sporo z nich teraz, niektóre z nich są dodawane do biblioteki, która kończy się jako stos losowych klas i modułów, niektóre wkraczają do aplikacji/modeli. Chciałbym to jakoś zorganizować, ale nie wiem od czego zacząć.

Jest to prawie w porządku w mojej książce. Jedyne, o czym nie wspomniałeś, to wydobywanie różnych kawałków w osobne klejnoty. Klasy rozmawiające z zewnętrznymi serwisami są doskonałymi kandydatami do ekstrakcji, podobnie jak klasy strategiczne, jeśli są wystarczająco ogólne. Mogą być prywatne, ponieważ uruchomienie własnego serwera klejnotów nie jest trudne i można je oczywiście ponownie wykorzystać w aplikacjach ROR.

Ostatnie i najbardziej konkretne zadania resque, które wkładam do biblioteki/zadań.

Moja zasada jest taka, że ​​jest to model rodzaju, który przechodzi w app/models. Jeśli nie, prawdopodobnie należy on do lib lub do jakiegoś odpowiednio nazwanego jego podkatalogu, np. lib/jobs, lib/extensions, lib/external lub tym podobne.

Answer 5

Jeśli jesteś zainteresowany, Napisałem też o tym artykuł uzupełniający, nieco później podsumowując to, co znalazłem: http://blog.lunarlogic.io/2013/declutter-lib-directory/