Wprowadzenie DoctrineORM do pradawnego systemu Opcje

[szczrzcz]

Mam do czynienia w pracy z ze starym systemem bez namespace, bez testów, bez ORM.
Przykładowa klasa modelu wygląda jak repozytorium z bardzo nieładnym kodem (niżej). Czy wprowadzenie Doctrine Orm (encji i relacji) do starego systemu z 90 tabelami wiąże się z jakimiś niesłychanymi problemami? Na mój rozumek to upierdliwe, ale do zrobienia. Czy w czasie remontu (dodawania kolejnych encji i relacji) dotychczasowy system będzie działał bez problemu? Proszę o porady jakie problemy mnie czekają, jakieś wskazówki. (wiem że istniało narzędzie które na podstawie bazy danych generuje encje i relacje, które wystarczy nieco popoprawiać)

poniżej jedna z klas "modelu", czyli 1000 linijek zapytań.
http://bin.devsphp.pl/d5a96ea4f45fd6dd4abb...86aeec2612a.xml
ps czy tak się kiedyś pisało klasy Modeli? modele to były metody z repozytoriami?

Ten post edytował szczrzcz 19.06.2017, 17:29:47

[kayman]

jak to w takich sytuacjach bywa, środowisko testowe, kopia bazy 1:1 i jazda, niech się wywala co chce, robota głupia strasznie (IMG:style_emoticons/default/smile.gif)

btw. jeżeli to shop to bym się zastanowił czy się go nie da przenieść na jakie magento presta etc

[szczrzcz]

ale rozumiem, że to w żaden sposób nie będzie kolidowało z istniejącym systemem jeśli encje Doctrine będę chciał używać do nowych funkcjonalności. Po prostu część systemu będzie se używać staroci a część nowych encji i wszystko będzie stało na jednej bazie danych na tych samych tabelach.

[kayman]

pracujesz na kopii 1:1 systemu i bazy np na subdomenie, oryginału nie ruszasz niech sobie pracuje dalej, jak doprowadzisz to do ładu podmieniasz oryginalny system (wcześniej i tak robisz backup bo można coś przeoczyć)

czasami szybciej wychodzi napisanie tego od początku (IMG:style_emoticons/default/smile.gif)

[szczrzcz]

ale ty zakładasz, że będę wymieniał w systemie wszystko co ma związek z bazą danych. A ja chcę tylko obok istniejącego folderu Model utworzyć Entity. I encji używac tylko do nowych modułów. Ten system i tak jest zasyfiony, tu nie chodzi o piękny kod a o przyjemność kodowania w przyszłości.

[kayman]

tak zakładam bo w praktyce tak to przeważnie wychodzi

wydaje mi się że wprowadzenie orm tam gdzie nie ma orm wiąże się z przepisaniem modeli (IMG:style_emoticons/default/smile.gif)

jeszcze te nowe modele odpowiadać temu co jest by nie przepisywać wszystkiego

[Pyton_000]

Powiem Ci tak... My np. postanowiliśmy przebudować system możliwie w 100% na SF3 z pradawnego kodu. Obok stoi sobie SF i routing przekierowuje albo na stary kod albo na nowy.

Z Doctrine będzie o tyle problem że musisz wygenerować Encje. Da się to zrobić automatem przez commands ale nie zawsze w 100% działa. Np. problemy z Enum (doctrine nie wspiera).
Także spokojnie możesz postawić obok Entity, zrobić wpięcie żeby móc się do doctrina wołać i jazda.

Chociaż zastanów się czy aby na pewno chcesz doctrine

[szczrzcz]

Chociaż zastanów się czy aby na pewno chcesz doctrine

co sugerujesz? Używałem tylko Doctrine.

[Pyton_000]

Chodzi o to czy to nie będzie przerostu formy nad treścią. Bo może warto np. przemodelować i używać czystego PDO.
Aczkolwiek jeśli uważasz że to będzie spoko to rób z Doctrine. Nie znamy architektury projektu więc ciężko doradzić (IMG:style_emoticons/default/smile.gif)

U mnie np. nie sprawdziło by się użycie dodatkowego ORM, a to co jest teraz działa na mysql_*

[szczrzcz]

machnąłem komendę:

Kod

doctrine orm:convert-mapping --from-database annotation /path/to/mapping-path-converted-to-yml

i już, póki co problemów nie widzę. Wygenerował mi ładnie encje, musiałem tylko dodać namespaces do każdej. Teraz będę na bieżąco poprawiał te klasy jeśli będę się zajmował konkretną i wyskoczy jakiś błąd. Fakt, że baza jest zaprojektowana bez kluczy obcych w tym wypadku okazało się błogosławieństwem (bo ponoć "reverse enginering" z tym ma właśnie problemy) . Ładnie mi wykrył relacje ManyToOne