Czy utrzymanie agnostyki naprawdę się opłaca?

Mam projekt, nad którym obecnie pracuję, używając Tomcat, Spring 4, Spring Security, MySQL i JPA w / Hibernate.

Wybrałem JPA z punktu widzenia, że ​​zamienianie podstawowej implementacji dostawców ORM jest płynne, a przynajmniej mniej bolesne. Powiedziałbym, że to mentalne użycie specyfikacji nad implementacją (JAX-RS) jest domyślnym punktem widzenia społeczności programistów Java.

Jestem ciekawy, czy to naprawdę warto zrobić. Jestem pewien, że gdybym użył Hibernacji bezpośrednio, zyskałbym trochę mocy, ponieważ mógłbym używać funkcji, które nie są częścią głównej specyfikacji JPA.

Część moich obaw wynika z pomysłu YAGNI. Zasadniczo programuję w określonym stylu i modzie (używając JPA zamiast Hibernacji), aby w pewnym momencie w przyszłości mogłem zamienić moją implementację ORM. Poważnie wątpię, aby kiedykolwiek wydarzyło się to przez cały okres użytkowania produktu, więc zasadniczo wkładam wysiłek w coś, z czego prawdopodobnie nigdy nie skorzystam.

Jakie są Twoje myśli? Czy warto „programować do interfejsu”, jeśli chodzi o takie rzeczy jak JPA? Czy kiedykolwiek zamieniłeś całą implementację ORM w produkcie? Czy kiedykolwiek udało ci się całkowicie uniknąć abstrakcji po przeciekaniu przez JPA? Ja osobiście mam już jedno natywne wywołanie SQL (aby wyczyścić tabele bazy danych) i jest coś, z czym chciałbym skorzystać, które są wbudowane w specyfikację JPA (pobierz / ustaw prefiksy do twoich metod i różnicę między MEMBER OF / IN, które wiążąc się tylko z bazową implementacją, pozwolą mi uniknąć.

aby w pewnym momencie w przyszłości mogłem zamienić moją implementację ORM. Poważnie wątpię, aby kiedykolwiek wydarzyło się to przez cały okres użytkowania produktu, więc w zasadzie wkładam wysiłek w coś, czego prawdopodobnie nigdy nie skorzystam

Z mojego doświadczenia wynika, że typowy projekt korporacyjny nigdy się nie zmienia:

1. Baza danych
2. ORM
3. Język

Nie znam liczb, ale odsetek aplikacji dwupoziomowych, które widziałem zaimplementowane, a następnie zmieniły jedną z tych rzeczy, prawdopodobnie byłby mniejszy niż 10%. Jeśli tak się stanie, zdarza się to rzadko i zwykle dzieje się to w ciągu pierwszych 2-3 miesięcy projektu, gdy ludzie są nadal w trybie odkrywania. Większość systemów, które znam, nadal działają na swoich oryginalnych platformach 8-10 lat później.

Częściej niż zamiana ORM, chcesz wiedzieć, co widziałem więcej? Całkowite usunięcie ORM, aby przejść do SQL z powodu problemów z wydajnością. Więc bez względu na to, w takim razie będziesz przepisywać różne rzeczy.

Jeśli chodzi o wdrażanie agnostyczne, to mit. To naprawdę sprowadza się do głupoty. Więc moim podejściem jest objęcie warstwy danych. Spraw, by była to pierwsza klasa Twojego języka i designu. To sprawia, że ​​projekty są szczęśliwsze i bardziej udane.

czy warto?
To całkowicie zależy od aplikacji.
Jeśli piszesz aplikację wewnętrzną dla jednej firmy, zapomnij o tym. Ta baza danych przeżyje aplikację o lata, a może nawet dekady.
Chyba że od samego początku zrozumiano, że w najbliższej przyszłości planowane jest zastąpienie bazy danych czymś innym.
Jeśli piszesz go na sprzedaż dla klientów, którzy mogą mieć różne silniki baz danych, A wymagania są takie, że powinien on obsługiwać wiele silników baz danych, TO ma sens.

Dla większości osób piszących aplikacje Java jest to w dużej mierze nieistotne.

Z mojego doświadczenia: nie, nie warto w przypadku JPA / Hibernacji.

Czy warto „programować do interfejsu”, jeśli chodzi o takie rzeczy jak JPA?

Jest, ale nie ma nic wspólnego z JPA. Możesz wykonać „programowanie interfejsów” Hibernacji. Tu nie chodzi o ukrywanie frameworka zgodnie ze standardem, chodzi o SOLID .

Czy kiedykolwiek zamieniłeś całą implementację ORM w produkcie?

Tak i nie. Jeden z produktów naszej firmy częściowo migrował z Hibernacji do jOOQ (który nie ma nic wspólnego z JPA). Nie był to dokładnie „typowy projekt dla przedsiębiorstw”, o którym wspomniał @codenheim, więc zamiana była możliwa.

Nie widzę sensu zamiany Hibernacji na inny ORM zgodny z JPA.

Czy kiedykolwiek udało ci się całkowicie uniknąć abstrakcji po przeciekaniu przez JPA?

Nie. Jest to niemożliwe, ponieważ zarówno JPA, jak i Hibernacja są bardzo złożone. I tak musisz poradzić sobie z problemami z wydajnością i wadami Hibernacji.

Ryzykując, że zabrzmi to sprzecznie, powiedziałbym, że tak, warto. I nie jest.

Problem polega nie tyle na zmianie ORM lub dostawcy bazy danych jako takiej. Chodzi raczej o oddzielenie problemów i zachowanie zwinności.

Kiedy zaczniesz polegać na pewnych szczegółach implementacji biblioteki, zaczniesz tworzyć coraz głębsze uwikłania problemów.

Jeśli wiesz, że Twoja implementacja ORM to Hibernacja, ta wiedza zaczyna wnikać w całą architekturę aplikacji. I ilekroć pojawia się nowa technologia, która wypiera Hibernację lub JPA tak dokładnie, jak Hibernacja zrobiła to, co było przed nią, okazuje się, że zależności stały się znacznie głębsze niż się spodziewałeś.

O wiele lepiej jest odrzucić całą troskę o utrwalenie modelu gdzieś na uboczu, gdzie wszystkie zawiłości w kontaktach z bazami danych i transakcjami itp. Mogą być łatwo zignorowane przez resztę aplikacji. W tym odległym ciemnym kącie możesz zawiązać węzły na szczegółach implementacji, jeśli chcesz - to naprawdę nie ma już znaczenia.

Problem z agnostycyzmem związanym z wdrażaniem polega na tym, że w czasie, gdy jesteś programistą, zmarnujesz czas w obu kierunkach.

Napisałem kilka projektów, w których marnowaliśmy mnóstwo czasu na pisanie do interfejsu, które nigdy nie były używane w żaden nowy sposób, nigdy nie były konwertowane i były używane „tak jak są” przez lata

Zmarnowałem też mnóstwo oprogramowania do konwersji czasu, którego nikt nigdy nie oczekiwał.

Jedyną prawdziwą obserwacją, którą muszę poczynić, jest to, że ta pierwsza jest o wiele mniej bolesna.