2012-05-07 11 views
20

Aktualnie tworzę 2 interfejsy API przy użyciu Ruby on Rails. Jeden do czytania (znajdowanie obiektów, odpytywanie), a drugi do pisania do niego, z udziałem skomplikowanego procesu z kolejkami i innym API. Obie aplikacje wymagają dokładnie tych samych modeli i logiki wewnątrz nich.Udostępnianie modeli między 2 interfejsami API Railsów (oddzielne aplikacje)

Moje pytanie brzmi: jaka jest najczęstsza najlepsza praktyka lub podejście do udostępniania specyfikacji modeli (relacje, zakresy, metody) między aplikacjami 2-szynowymi?

Dziękujemy!

+0

można zmienić kod w obu API? czy jest jakieś ograniczenie? –

+0

@NigelThorne Z pewnością mogę, oba są zbudowane przeze mnie. – Gotjosh

Odpowiedz

4

Sposób, w jaki to zrobię, to "Silnik do zamontowania". Sprawdź doskonałe Railscast by Ryan Bates na początek i engine-section at api.rubyonrails.org w celu uzyskania dalszych szczegółów.

Z poważaniem, Mandi

+0

Railscast ma być przeznaczony do nowych aplikacji, ale pierwszy API już jest zrobiony, poza tym, że silnikami współdzieliłbyś kontrolery i widoki, jeśli mam rację, co nie jest moim przypadkiem ... – Gotjosh

+2

@Gotjosh Możesz wyodrębnić istniejące modele do silnika (najlepiej zapakowanego w klejnot). Następnie dołącz ten klejnot do starej aplikacji i voila, twoje modele są dostępne. Możesz dołączyć klejnot do dowolnej aplikacji, którą lubisz. I nie, silniki nie zapewniają automatycznie kontrolerów.Silnik może dostarczyć dowolne lub wszystkie elementy aplikacji Rails, modele, widoki, kontrolery, pliki zasobów (JS, CSS) itp. Dobra książka na ten temat to "Crafting Rails Applications" José Valima. –

1

Jeśli chcesz po prostu podzielić się modele, ty może dodać inny folder modeli projektów do ścieżki automatycznego ładowania s:

rails new test1 
rails new test2 
cd test1 
rails g model User 
cd ../test2/ 
# ACTION REQUIRED: edit config/application.rb adding this line 
# inside the class Application < Rails::Application block: 
# 
# config.autoload_paths += %W(#{config.root}/../test1/app/models) 
# 
mkdir db/migrate 
cp ../test1/db/migrate/*_create_users.rb db/ 
mv db/*_create_users.rb db/migrate/ 
rake db:migrate 
rails r 'puts User.inspect' 
#=> User(id: integer, created_at: datetime, updated_at: datetime) 

Można również ustawić całość w celu uzyskania dwóch app/models foldery jako prywatny, wykorzystując trzecią folderu udostępnionego, dodając to do projektów:

# config.autoload_paths += %W(/path/to/a/shared/folder) 

tego folderu można nawet nie jest tym samym folderem dla każdego projektu, więc może to być ścieżka do modułu częściowego git, na przykład (jeśli używasz GIT, polecam to rozwiązanie).

Innym rozwiązaniem mogłoby być skierowane app/models do udostępnionego folderu miękką linku

1

Mój podstęp dla tego rozwiązania jest to, aby nie używać sztuczek rzeczywiście szynach. Używam sztuczek "git" i ściągam kod z 3. repozytorium z udostępnionym kodem. Umieściłem to w obu aplikacjach jako silnik i jako zewnętrzny odnośnik git.

To trochę więcej pracy, ale gdy raz to zrobisz w jednej aplikacji, możesz z łatwością użyć tego jako szablonu do następnego.

+0

Czy to nie oznacza, że ​​musisz przesłać zmiany w jednej aplikacji do Git, zanim zobaczysz je w innej aplikacji? Jak opracowałbyś i przetestowałeś coś nowego? Co rozumiesz przez "silnik"? – Chloe

Powiązane problemy