Dzisiejsze opcje łatwiejszej ścieżki migracji do Play 2

Jestem nowy w Scali i Play, i rozważam wykorzystanie ich do nowego projektu. Widzę, że rozwój w Play 2 dobrze się układa, chociaż stabilna wersja to nadal 1.x. I między nimi jest substantial differences.Dzisiejsze opcje łatwiejszej ścieżki migracji do Play 2

Zastanawiam się, jeśli teraz rozpocznę projekt Play 1.x, jakie opcje mogę zastosować, aby ułatwić migrację do gry 2 w przyszłości?

Mianowicie:

play 2 wykorzystuje Ebean jako domyślny ORM, byś doradzić mi go używać zamiast ORM Odtwórz 1.x za (hibernacji)?
Co z systemem szablonów; cokolwiek mogę teraz zrobić, aby ułatwić późniejszą migrację?
O co jeszcze muszę się martwić, gdy zdecyduję się przenieść moją aplikację do Play 2 w przyszłości?

Źródło

2011-11-25 Filipe Correia

Na samej migracji:

Nie jesteś plany migracji Groovy szablony grać 2 (uważam, że jest w toku). Możesz złagodzić to, że zaczynasz używać Play 1.x ze Scala, ponieważ system szablonów będzie to Scala.
Zmiana z Hibernuj na Ebean powinna być łatwa, chyba że korzystasz z rozszerzeń specyficznych dla Hibernacji.
Konfiguracja i niektóre zadania (takie jak @OnApplicationStart) mogą ulec zmianie, ale powinno to być dość łatwe do przeniesienia (wystarczy je przenieść).
Będą zmiany w sposobie dostępu do tras i zasobów, co może dać dodatkową pracę dostosowując kod/szablony.

Generalnie nie powinno być to zbyt skomplikowane, ale jak powiedział @lacy, zależy to od terminów i samego projektu. Jeśli jest to projekt krytyczny, który zostanie ukończony przed przyszłym marcem 2012 r., Wybrałbym Play 1.1. Jeśli jest to mniej ważny projekt, który może być opóźniony, a w każdym razie nie zostanie opublikowany przed marcem 2012 r., Spróbuj Play 2.0.

Źródło

2011-11-25 08:06:47

Więc mówimy, że jeśli użyję wersji SCALA w wersji 1.x, moje szablony będą kompatybilne z Play 2 out-of-the-box? –

Co się tyczy ORM, tak samo, jak długo trzymam się z dala od rozszerzeń hibernacji? –

@Filipe Correia, jeśli używasz Scala, tak, szablony wydają się być zgodne (to beta, może się to zmienić, ale na pewno nic poważnego). W ORM, EBean jest zgodny z JPA AFAIK, więc nie powinieneś mieć żadnych problemów. –

To wszystko na temat terminów projektu. Niedługo pojawi się Play2, a niektóre komponenty już wydają się całkiem stabilne. Tak więc, jeśli czas na to pozwoli, polecam używanie Play2. Ostatnio zmieniono status na Beta. Kilka dni temu Guillaume stworzył przydatny wiki na Github. Możesz również zwrócić uwagę na przykłady ze źródeł Play2. I, jak rozumiem, nie będzie wytycznych dotyczących migracji od Play1X do Play2.

Źródło

2011-11-25 01:38:58 viktortnk

Podczas przeskakiwania do gry 2 z pewnością uniknęlibyśmy problemów związanych z migracją, wszyscy członkowie zespołu będą nowi w Scali i PLay, a ja wolę unikać wszelkich dodatkowych tarć. Jestem przekonany, że nadal chcę korzystać z Play 1.x. w przypadku tego projektu, ale chcę zminimalizować wszelkie wysiłki związane z migracją, które będziemy mieć, gdy Play 2 będzie gotowy do produkcji.Stąd moje pytanie, jakie opcje/wytyczne/konwencje powinienem użyć, aby ułatwić to przejście? –

Nawet nie zawracałbym sobie głowy wykorzystaniem Play2 w projekcie. Wciąż brakuje niektórych funkcji, a nawet jeśli rozwój będzie kontynuowany, pozostanę przy Play 1.2.x. Nawet jeśli muszę przyznać, to kusi, aby spróbować 2.0.

Ale nigdy nie wybrałbym pomiędzy rozwiązaniem. Zaczynając od Play 1.2.x i próbując przejść na wersję 2.0.0. Nazywa się Semantic Versionning. Gdy główna liczba wzrasta, nie ma kompatybilności wstecznej. Oznacza to, że używasz gry w wersji 1.2.x lub Play 2.0. Próba migracji spowoduje więcej stresu, problemów, niż chcesz.

Źródło

2011-11-25 13:20:54

Cóż, to chyba zależy? Mam nadzieję, że jest moment, w którym zalety Play 2 przeważą koszt przeniesienia z 1.x. Mój problem polega na tym, co mogę teraz zrobić, aby upewnić się, że koszty będą tak niskie, jak to możliwe, nawet jeśli nie są one pomijalne. –

Dzisiejsze opcje łatwiejszej ścieżki migracji do Play 2

Odpowiedz

Powiązane problemy