Czy ORM jest anty-wzorcem? [Zamknięte]

Przeprowadziłem bardzo stymulującą i interesującą dyskusję z kolegą na temat ORM oraz jego zalet i wad. Moim zdaniem ORM jest użyteczny tylko w najrzadszych przypadkach. Przynajmniej z mojego doświadczenia.

Ale nie chcę teraz wymieniać własnych argumentów. Pytam więc, co sądzisz o ORM? Jakie są zalety i wady?

Występuje dość duży i zróżnicowany zestaw trudności koncepcyjnych i technicznych podczas próby podejścia do relacyjnej bazy danych z punktu widzenia obiektowego. Trudności te są wspólnie znane jako niedopasowanie impedancji relacyjnej względem obiektu, a powiązany artykuł w Wikipedii jest niezwykle pouczający. W artykule wymieniono sporo, nie widzę tutaj żadnego sensownego sposobu ich opisania. Aby dać ogólny pomysł, są one skatalogowane jako:

• Niedopasowania
  • Koncepcje obiektowe
  • Różnice typów danych
  • Różnice strukturalne i integralności
  • Różnice manipulacyjne
  • Różnice transakcyjne
• Rozwiązywanie niedopasowania impedancji
  • Minimalizacja
  • Alternatywne architektury
  • Odszkodowanie
• Twierdzenie
• Różnice filozoficzne

Myślę, że jeśli poświęcisz trochę czasu na przeczytanie tego artykułu, zrozumiesz, że fakt, że ORM jest czasami opisywany jako anty-wzór, jest w rzeczywistości nieunikniony. Te dwie domeny są tak różne, że każde podejście do traktowania jednej jako drugiej jest domyślnie anty-wzorem, w tym sensie, że anty-wzór jest wzorcem sprzecznym z filozofią domeny.

Ale nie sądzę, że termin ten powinien odnosić się do wszystkiego, co zasadniczo działa jako pomost między dwiema bardzo różnymi domenami. Oznaczanie wzoru jako anty-wzorca ma sens tylko w jego dziedzinie. Zatem pytanie, czy jest to anty-wzór, czy nie, nie ma znaczenia.

Ale czy to jest przydatne? Tak ORM jest jednym z najbardziej użytecznych anty-wzorów. Zrozumiesz dlaczego tylko wtedy, gdy znajdziesz się w praktycznej sytuacji, w której będziesz musiał zamienić bazy danych w projekcie. Lub nawet uaktualnij do innej wersji tej samej bazy danych. ORM to jedna z tych rzeczy, które w pełni rozumiesz tylko wtedy, gdy naprawdę ich potrzebujesz.

Oczywiście, ponieważ wszystko przydatne, ORM jest bardzo podatny na nadużycia. Jeśli uważasz, że to w jakiś sposób zastępuje potrzebę wiedzy o bazie danych, nad którą pracujesz, to wróci i cię ugryzie. Ciężko.

Na koniec pozwól mi bezwstydnie wstawić jedną z moich odpowiedzi na powiązany „Czy wzorzec ActiveRecord przestrzega / zachęca do zasad projektowania SOLID?” pytanie, które jest dla mnie o wiele bardziej istotne niż „czy jest to anty-wzór”.

Jest to podobne do pytania „czy wiertarka jest anty-wzorem?”. ORM zyskały dobre miejsce w moim zestawie narzędzi, zmniejszając mój kod typu „płyta grzewcza” i nadal mogę używać niestandardowego SQL, jeśli to konieczne. Więc jeśli jest to anty-wzór, który wzór jest przeciwny?

Moja odpowiedź brzmi: nie, istnieje wiele dojrzałych ORM, które znacznie ułatwiają życie i sprawiają, że kod jest bardziej zrozumiały. To w żaden sposób oznacza, że ​​nie musisz rozumieć SQL, wręcz przeciwnie.

Z wahaniem nazwałbym coś „anty-wzorcem”, który został po raz pierwszy nazwany wzorem przez Martina Fowlera i od tego czasu jest stosowany w prawie każdym nowoczesnym języku programowania. (Zobacz artykuł w Wikipedii na temat ActiveRecord .)

Dobra ORM może prowadzić do znacznie mniejszego kodu (i znacznie mniej powtórzeń) w projekcie i nic nie jest tak silnie skorelowane z błędami jak ilość oryginalnego kodu.

ORM są ogólnie zaprojektowane do obsługi najczęstszych przypadków użycia do pracy z bazami danych. Złożone zapytania mogą nadal wymagać wyraźnego napisania. Ale zdecydowanie zalecałbym pisanie wyraźnych zapytań dla każdej interakcji z bazą danych. W większości przypadków jest to strata czasu.

Używanie ORM zamiast nauki SQL jest dość złym pomysłem. Jeśli nie wiesz dokładnie, jaki rodzaj SQL jest generowany, jeśli nie rozumiesz problemów N + 1 i jak je zoptymalizować, to na pewno spowoduje więcej szkody niż pożytku. Wydaje mi się jednak, że jestem znacznie bardziej produktywny dzięki ORM. Wolę Rails ActiveRecord, który nie próbuje udawać, że nie ma bazy danych i nie przeszkadza, jeśli potrzebujesz tylko napisać SQL. Martwię się jednak, że niektórzy ludzie mogą ufać idiomom, które widzą zbyt głęboko, bez głębokiego zrozumienia tego, co robią.

Moje doświadczenie: używam NHibernate z Linq2NHibernate.

Plusy:

• Pozbywa się „Magicznych sznurków” lub przynajmniej oferuje miejsce, w którym można je umieścić
• Pozwala mi to cały czas pracować w paradygmacie OO
• Kod jest łatwiejszy do odczytania
• Kod zbudowany na górze jest łatwiejszy do zmiany
• Umożliwia wymianę rzeczywistej relacyjnej bazy danych bez konieczności utrzymywania 2 osobnych repozytoriów (rzadko wykonywane, ale jest to jedna wielka korzyść, jeśli jej potrzebujesz).

Cons:

• Kod jest trudniejszy do napisania , ponieważ
• To nie jest wystarczająca abstrakcja - nadal musisz dokładnie zapoznać się z tym, co robi w tle

Powiem, że nie spełnia obietnicy, na którą początkowo ma nadzieję większość ludzi. Nie winiłbym kogoś za to, że powiedział, że to anty-wzór. W moim przypadku nadal muszę przeprowadzić testy integracyjne z bazą danych SQLite, aby upewnić się, że moje zapytania Linq2NHibernate faktycznie działają. Tak naprawdę, jeśli i tak przeprowadzasz testy integracyjne z prawdziwą relacyjną bazą danych, to eliminuje to problem z „magicznymi łańcuchami”.

Gdybym miał rozpocząć nowy projekt, nie jestem pewien, czy użyłbym ORM, czy nie. Prawdopodobnie bym to zrobił, ale nie mogę powiedzieć, że powinieneś. Powiedziałbym, że to jest różnica między wyborem C ++ lub Java / .NET dla twojego projektu: czy będziesz potrzebować elastyczności, którą uzyskasz pracując na niższym poziomie, czy raczej wolisz pracować na wyższym poziomie i (podobno) być bardziej produktywny? Normalną odpowiedzią jest praca na tak wysokim poziomie, jak to tylko możliwe . Zazwyczaj oznacza to użycie ORM.

Siłą ORM jest to, że pozwala modelować zachowanie aplikacji przy użyciu technik obiektowych. W starannie zaprojektowanym świecie dostępna jest jedna warstwa aplikacji, w której język firmy idealnie pasuje do języka zespołu programistów. ORM umożliwia to, jeśli ORM jest używany rozsądnie.

Słabość polega na tym, że liczba osób, które tak naprawdę naprawdę korzystają z programowania obiektowego, jest niewielka. Wiele osób pisze spaghetti i klopsiki, z silnie sprzężonymi obiektami, które mają małe własne zachowania, a rzeczywiste zachowanie kończy się w ohydnych 8000-liniowych klasach „Service” i „Manager”, a ten kod jest często tak zawiły, że wszyscy się boją zmiany, ponieważ nie mogą dowiedzieć się, jakie będą skutki uboczne.

Ponadto wiele osób tak naprawdę nie ma modelu relacyjnego. ORM nie pomoże im go zdobyć i nie pomoże im poprzez wyodrębnienie modelu relacyjnego. Pozwala to tylko wcześnie skoncentrować się na warstwie domeny i uzyskać ją tuż przed nadmiernym zaniepokojeniem projektem bazy danych. Jeśli jest dobrze zastosowany, za pomocą rozsądnych narzędzi do migracji schematów, a ORM może pomóc w zapobieganiu narastaniu długów kodu.

Zbudowałem aplikacje, w których ORM zapewniał prosty, czytelny i testowalny kod aplikacji oraz miał odpowiednią wydajność. Zachowałem również aplikacje, w których wzorzec był niewłaściwie używany, a kod był zawiły, niestabilny, wolny i delikatny; okazuje się, że ORM nie miał z tym wiele wspólnego, poza tym, że zamiast pisać zły kod, który źle modelował domenę aplikacji, starszy zespół inżynierów napisał zły kod, który źle modelował domenę aplikacji ORAZ zły kod warstwy usług, który pomijał wszystkie wartość, którą może zapewnić ich ORM.

ORM nie uczynią cię mądrzejszym, ale w rękach właściwego programisty może prowadzić do łatwiejszego w utrzymaniu i wyższej jakości kodu.

Być może odpowiedź leży w pytaniu: czy przechowywanie danych aplikacji w czymś innym niż relacyjna baza danych jest dobrym pomysłem? Jakie problemy eliminujesz i jakie inne problemy odbierasz? Czy potrafisz żyć bez możliwości łatwego odsyłania do danych (łączenia) lub szybkiego odfiltrowywania rekordów, które chcesz na podstawie wielu kryteriów? Czy nie potrzebujesz solidnego wsparcia transakcji (zakładając, że Twoja alternatywa go nie ma)? Nie wszystkie aplikacje wymagają zawsze spójnego i kompletnego magazynu danych.

Myślę, że prawdziwym anty-wzorcem tutaj może być używanie relacyjnej bazy danych, kiedy jej nie potrzebujesz. Jeśli potrzebujesz, potrzebujesz ORM i zdecydowanie nie jest to anty-wzór.

ORM to narzędzie. Podobnie jak wszystkie narzędzia, gdy są właściwie używane, działają całkiem dobrze. W przypadku niewłaściwego użycia potrzebuje większego młotka i taśmy izolacyjnej.

W przypadku obecnego projektu, nad którym pracuję, będzie on utrzymywany przez nie-programistów (a dokładniej inżynierów mechaników), więc musi być prosty i łatwy do rozgryzienia. Upłynie kilka lat, zanim grupa ta będzie miała budżet na zatrudnienie programistów (zakładając, że następny prezydent nie zniesie zaangażowanej agencji), więc przyszłe możliwości utrzymania są głównym czynnikiem naszych rozważań.