Czy istnieją dobre powody, aby nie używać ORM? [Zamknięte]

Podczas mojej praktyki korzystałem z NHibernate w kilku mniejszych projektach, które głównie kodowałem i projektowałem samodzielnie. Teraz, przed rozpoczęciem większego projektu, pojawiła się dyskusja, jak zaprojektować dostęp do danych i czy używać warstwy ORM. Ponieważ wciąż jestem na stażu i nadal uważam się za początkującego w programowaniu dla przedsiębiorstw, moim zdaniem nie próbowałem naciskać, ponieważ używanie mapowania relacyjnego obiektu do bazy danych może znacznie ułatwić rozwój. Pozostali programiści w zespole programistów są znacznie bardziej doświadczeni niż ja, więc myślę, że zrobię to, co powiedzą. :-)

Jednak nie do końca rozumiem dwa główne powody, dla których nie używam NHibernate lub podobnego projektu:

1. Można po prostu zbudować własne obiekty dostępu do danych za pomocą zapytań SQL i skopiować te zapytania z Microsoft SQL Server Management Studio.
2. Debugowanie ORM może być trudne.

Tak więc, oczywiście, mógłbym po prostu zbudować warstwę dostępu do danych z dużą ilością SELECTs itp., Ale tutaj brakuje mi zalet automatycznego łączenia, leniwego ładowania klas proxy i mniejszego wysiłku związanego z konserwacją, jeśli tabela otrzyma nową kolumnę lub kolumna zmieniono nazwę. (Aktualizacja liczne SELECT, INSERTi UPDATEzapytań vs. aktualizowanie config mapowania i ewentualnie refactoring klas biznesowych i DTOs).

Ponadto, używając NHibernate możesz napotkać nieprzewidziane problemy, jeśli nie znasz dobrze struktury. Może to być na przykład zaufanie do pliku Table.hbm.xml, w którym ustawiasz długość łańcucha do automatycznego sprawdzania poprawności. Jednak mogę również wyobrazić sobie podobne błędy w „prostej” warstwie dostępu do danych opartej na zapytaniach SqlConnection.

Wreszcie, czy te argumenty wspomniane powyżej są naprawdę dobrym powodem, aby nie wykorzystywać ORM w nietrywialnej aplikacji korporacyjnej opartej na bazie danych? Czy prawdopodobnie są inne argumenty, które mogliby przegapić?

(Powinienem chyba dodać, że myślę, że jest to pierwsza „duża” aplikacja oparta na .NET / C #, która będzie wymagała pracy zespołowej. Dobre praktyki, które są postrzegane jako całkiem normalne w przypadku przepełnienia stosu, takie jak testy jednostkowe lub ciągła integracja, nie są -istniejący tutaj do teraz.)

W ostatnich latach nastąpił gwałtowny wzrost liczby ORMów i Twoi bardziej doświadczeni współpracownicy mogą nadal myśleć, że „każde wywołanie bazy danych powinno odbywać się za pośrednictwem procedury składowanej”.

Dlaczego ORM miałby utrudniać debugowanie? Otrzymasz ten sam wynik, niezależnie od tego, czy pochodzi z przechowywanego procesu, czy z ORM.

Myślę, że jedyną prawdziwą szkodą, o której mogę pomyśleć w przypadku ORM, jest to, że model bezpieczeństwa jest nieco mniej elastyczny.

EDYCJA: Właśnie ponownie przeczytałem twoje pytanie i wygląda na to, że kopiują i wklejają zapytania do wbudowanego sql. To sprawia, że ​​model bezpieczeństwa jest taki sam jak ORM, więc nie byłoby absolutnie żadnej przewagi nad tym podejściem nad ORM. Jeśli używają niesparametryzowanych zapytań, w rzeczywistości byłoby to zagrożenie bezpieczeństwa.

Krótka odpowiedź brzmi: tak, są naprawdę dobre powody. W rzeczywistości zdarzają się przypadki, w których po prostu nie możesz użyć ORM.

Na przykład pracuję dla instytucji finansowej dużego przedsiębiorstwa i musimy przestrzegać wielu wytycznych dotyczących bezpieczeństwa. Aby spełnić nałożone na nas zasady i przepisy, jedynym sposobem na przejście audytów jest utrzymanie dostępu do danych w ramach procedur składowanych. Niektórzy mogą powiedzieć, że to po prostu głupie, ale szczerze mówiąc, tak nie jest. Korzystanie z narzędzia ORM oznacza, że ​​narzędzie / programista może wstawiać, wybierać, aktualizować lub usuwać, co tylko zechce. Procedury składowane zapewniają dużo większe bezpieczeństwo, zwłaszcza w środowiskach, w których mamy do czynienia z danymi klientów. Myślę, że to największy powód do rozważenia. Bezpieczeństwo.

Słodki punkt ORMów

ORM są przydatne do automatyzacji ponad 95% zapytań tam, gdzie mają one zastosowanie. Ich szczególna siła polega na tym, że masz aplikację z silną architekturą modelu obiektowego i bazą danych, która dobrze współgra z tym modelem obiektowym. Jeśli tworzysz nową wersję i masz duże umiejętności modelowania w swoim zespole, prawdopodobnie uzyskasz dobre wyniki z ORM.

Możesz mieć kilka zapytań, które lepiej wykonać ręcznie. W takim przypadku nie bój się napisać kilku procedur składowanych, aby sobie z tym poradzić. Nawet jeśli zamierzasz przenieść swoją aplikację na wiele platform DBMS, kod zależny od bazy danych będzie stanowił mniejszość. Mając na uwadze, że będziesz musiał przetestować swoją aplikację na dowolnej platformie, na której zamierzasz ją obsługiwać, trochę dodatkowego wysiłku związanego z przenoszeniem niektórych procedur składowanych nie będzie miało większego wpływu na całkowity koszt posiadania. Dla pierwszego przybliżenia, 98% przenośnych jest tak samo dobre jak w 100% przenośne i znacznie lepsze niż skomplikowane lub słabo działające rozwiązania do obejścia ograniczeń ORM.

Widziałem, że to pierwsze podejście działa dobrze w bardzo dużym (100 lat personelu) projekcie J2EE.

Gdzie ORM może nie być najlepszym rozwiązaniem

W innych przypadkach mogą istnieć podejścia, które lepiej pasują do aplikacji niż ORM. Fowler Patterns of Enterprise Application Architecture zawiera sekcję dotyczącą wzorców dostępu do danych, która całkiem nieźle radzi sobie z katalogowaniem różnych podejść do tego zagadnienia. Oto kilka przykładów sytuacji, w których ORM może nie mieć zastosowania:

• W aplikacji ze znaczną starszą bazą kodową procedur składowanych możesz chcieć użyć funkcjonalnie zorientowanej (nie mylić z językami funkcjonalnymi) warstwy dostępu do danych, aby opakować istniejące SPROC. Powoduje to ponowne wykorzystanie istniejącej (a zatem przetestowanej i debugowanej) warstwy dostępu do danych i projektu bazy danych, co często stanowi dość znaczny wysiłek związany z rozwojem i testowaniem, a także pozwala zaoszczędzić na konieczności migracji danych do nowego modelu bazy danych. Często jest to całkiem dobry sposób na owijanie warstw Java wokół starszych baz kodu PL / SQL lub ponowne ukierunkowanie na bogate aplikacje klienckie VB, Powerbuilder lub Delphi z interfejsami internetowymi.

• Odmiana polega na dziedziczeniu modelu danych, który niekoniecznie jest dobrze dopasowany do mapowania LUB. Jeśli (na przykład) piszesz interfejs, który wypełnia lub wyodrębnia dane z obcego interfejsu, być może lepiej będzie pracować bezpośrednio z bazą danych.

• Aplikacje finansowe lub inne typy systemów, w których ważna jest integralność danych między systemami, szczególnie jeśli używasz złożonych transakcji rozproszonych z zatwierdzaniem dwufazowym. Być może będziesz musiał zarządzać swoimi transakcjami lepiej niż ORM jest w stanie obsłużyć.

• Aplikacje o wysokiej wydajności, w których chcesz naprawdę dostroić dostęp do bazy danych. W takim przypadku może być lepsza praca na niższym poziomie.

• Sytuacje, w których korzystasz z istniejącego mechanizmu dostępu do danych, takiego jak ADO.Net, który jest „wystarczająco dobry” i dobrze się bawisz z platformą, są bardziej korzystne niż ORM.

• Czasami dane to tylko dane - może się zdarzyć (na przykład), że Twoja aplikacja działa z „transakcjami”, a nie z „obiektami” i jest to rozsądny pogląd na domenę. Przykładem może być pakiet finansowy, w którym masz transakcje z konfigurowalnymi polami analizy. Chociaż sama aplikacja może być zbudowana na platformie OO, nie jest powiązana z modelem jednej domeny biznesowej i może nie być świadoma niczego więcej niż kody GL, konta, typy dokumentów i pół tuzina pól analizy. W takim przypadku aplikacja nie zna modelu domeny biznesowej jako takiego, a model obiektowy (poza samą strukturą księgi) nie jest odpowiedni dla aplikacji.

Po pierwsze - użycie ORM nie ułatwi testowania kodu, ani też nie zapewni żadnych korzyści w scenerii Continuous Integration.

Z mojego doświadczenia wynika, że ​​chociaż korzystanie z ORM może przyspieszyć rozwój, największe problemy, które należy rozwiązać, to:

1. Testowanie kodu
2. Utrzymanie kodu

Rozwiązania tego są następujące:

1. Spraw, aby Twój kod był testowalny (używając zasad SOLID )
2. Napisz testy automatyczne dla jak największej części kodu
3. Uruchamiaj testy automatyczne tak często, jak to możliwe

Wracając do twojego pytania, dwa zastrzeżenia, które wymieniasz, wydają się bardziej ignorancją niż czymkolwiek innym.

Brak możliwości ręcznego pisania zapytań SELECT (co, jak przypuszczam, jest powodem, dla którego potrzebne jest kopiowanie i wklejanie) wydaje się wskazywać, że istnieje pilna potrzeba szkolenia SQL.

Są dwa powody, dla których nie użyłbym ORM:

1. Jest to surowo zabronione przez politykę firmy (w takim przypadku pójdę pracować gdzie indziej)
2. Projekt wymaga bardzo dużej ilości danych, a korzystanie z rozwiązań specyficznych dla dostawców (takich jak BulkInsert) ma większy sens.

Typowe odrzucenia dotyczące ORM (w szczególności NHibernate) to:

1. Prędkość

   Nie ma powodu, dla którego korzystanie z ORM byłoby wolniejsze niż ręcznie kodowany dostęp do danych. W rzeczywistości, dzięki wbudowanemu buforowaniu i optymalizacji, może być szybszy. Dobry ORM wygeneruje powtarzalny zestaw zapytań, dla których możesz zoptymalizować swój schemat. Dobry ORM umożliwi również wydajne pobieranie powiązanych danych przy użyciu różnych strategii pobierania.

2. Złożoność

   Jeśli chodzi o złożoność, użycie ORM oznacza mniej kodu, co ogólnie oznacza mniejszą złożoność. Wiele osób korzystających z dostępu do danych napisanego odręcznie (lub wygenerowanego kodem) piszą własne ramy w bibliotekach dostępu do danych „niskiego poziomu” (np. Pisząc metody pomocnicze dla ADO.Net). Są one równoznaczne z większą złożonością, a co gorsza, rzadko są dobrze udokumentowane lub dobrze przetestowane.
   Jeśli patrzysz konkretnie na NHibernate, narzędzia takie jak Fluent NHibernate i Linq To NHibernate również złagodzą krzywą uczenia się.

W całej debacie na temat ORM rozumiem, że ci sami ludzie, którzy twierdzą, że używanie ORM będzie zbyt trudne / powolne / cokolwiek, są tymi samymi ludźmi, którzy są bardziej niż zadowoleni z używania Linq To Sql lub Typed Datasets. Podczas gdy Linq To Sql jest dużym krokiem we właściwym kierunku, wciąż jest lata świetlne w tyle za niektórymi otwartymi źródłami ORM. Jednak ramy zarówno dla typów danych, jak i dla Linq To Sql są nadal niezwykle złożone, a używanie ich do przesuwania się za daleko od (Table = Class) + (basic CRUD) jest głupio trudne.

Moja rada jest taka, że ​​jeśli pod koniec dnia nie możesz uzyskać ORM, upewnij się, że dostęp do danych jest oddzielony od reszty kodu i postępujesz zgodnie z radą Gang Of Four w zakresie kodowania, aby interfejs. Zdobądź także framework Dependancy Injection, aby wykonać okablowanie.

(Jak to wygląda dla tyrady?)

Istnieje wiele typowych problemów, w przypadku których narzędzia ORM, takie jak Hibernate, są wysyłane przez Boga, a kilka z nich stanowi przeszkodę. Nie wiem wystarczająco dużo o Twoim projekcie, aby wiedzieć, który to jest.

Jedną z mocnych stron Hibernate jest to, że możesz powiedzieć coś tylko 3 razy: każda właściwość jest wymieniona w klasie, pliku .hbm.xml i bazie danych. W przypadku zapytań SQL Twoje właściwości znajdują się w klasie, bazie danych, instrukcjach select, instrukcjach insert, instrukcjach update, instrukcjach delete oraz całym kodzie krosowania i unmarshalling obsługującym zapytania SQL! Może to szybko stać się bałaganiarskie. Z drugiej strony wiesz, jak to działa. Możesz to debugować. Wszystko jest w twojej własnej warstwie trwałości, a nie w trzewiach narzędzia innej firmy.

Hibernate może być dzieckiem plakatu Prawa nieszczelnych abstrakcji Spolsky'ego. Zejdź trochę z utartej ścieżki i musisz znać głębokie wewnętrzne działanie narzędzia. To może być bardzo irytujące, kiedy wiesz, że mogłeś naprawić kod SQL w kilka minut, ale zamiast tego spędzasz godziny na próbach nakłonienia swojego narzędzia do wygenerowania rozsądnego SQL. Debugowanie bywa koszmarem, ale trudno jest przekonać ludzi, których tam nie było.

EDYCJA: Możesz zajrzeć do iBatis.NET, jeśli nie zamierzają odwrócić ich uwagi od NHibernate i chcą mieć kontrolę nad swoimi zapytaniami SQL.

EDYCJA 2: Tutaj jest jednak duża czerwona flaga: „Dobre praktyki, które są postrzegane jako całkiem normalne w przypadku przepełnienia stosu, takie jak testy jednostkowe lub ciągła integracja, nie istnieją do tej pory”. A więc, ci „doświadczeni” programiści, czego mają doświadczenie w programowaniu? Bezpieczeństwo pracy? Wygląda na to, że możesz być wśród ludzi, którzy nie są szczególnie zainteresowani tą dziedziną, więc nie pozwól im zabić twojego zainteresowania. Musisz zachować równowagę. Podejmij walkę.

Pracowałem nad jednym projektem, w którym niestosowanie ORM było bardzo skuteczne. To był projekt, który

1. Od początku musiał być jednak skalowany w poziomie
2. Musiał zostać szybko opracowany
3. Miał stosunkowo prosty model domeny

Czas, jaki zajęłoby uruchomienie NHibernate w strukturze podzielonej poziomo, byłby znacznie dłuższy niż czas potrzebny na opracowanie super prostego programu do mapowania danych, który był świadomy naszego schematu partycjonowania ...

Tak więc w 90% projektów, nad którymi pracowałem nad ORMem, było nieocenioną pomocą. Ale są pewne bardzo specyficzne okoliczności, w których uważam, że nie używanie ORM jest najlepsze.

Pozwólcie, że najpierw powiem, że ORMy mogą ułatwić życie programistyczne, jeśli są odpowiednio zintegrowane, ale jest kilka problemów, w których ORM może faktycznie uniemożliwić osiągnięcie określonych wymagań i celów.

Zauważyłem, że podczas projektowania systemów, które mają wysokie wymagania dotyczące wydajności, często muszę znaleźć sposoby na zwiększenie wydajności systemu. Wiele razy otrzymuję rozwiązanie, które ma wysoki profil wydajności zapisu (co oznacza, że ​​zapisujemy dane o wiele więcej niż czytamy dane). W takich przypadkach chcę skorzystać z udogodnień, które oferuje mi platforma bazy danych, aby osiągnąć nasze cele wydajnościowe (to OLTP, a nie OLAP). Więc jeśli używam SQL Server i wiem, że mam dużo danych do zapisania, dlaczego nie miałbym użyć wstawiania zbiorczego ... cóż, jak już mogłeś odkryć, większość ORMS (nie wiem, czy nawet pojedynczy) nie mają możliwości skorzystania z zalet specyficznych dla platformy, takich jak zbiorcze wstawianie.

Powinieneś wiedzieć, że możesz łączyć techniki ORM i inne niż ORM. Właśnie odkryłem, że istnieje kilka skrajnych przypadków, w których ORM nie mogą spełnić twoich wymagań i musisz je obejść w tych przypadkach.

Kiedy musisz zaktualizować 50000000 rekordów. Ustaw flagę lub cokolwiek.

Spróbuj to zrobić za pomocą ORM bez wywoływania procedury składowanej lub natywnych poleceń SQL.

Aktualizacja 1: Spróbuj również pobrać jeden rekord z tylko kilkoma jego polami. (Kiedy masz bardzo „szeroki” stół). Albo wynik skalarny. ORMy też są do tego kiepskie.

UPDATE 2 : Wygląda na to, że EF 5.0 beta obiecuje aktualizacje wsadowe, ale to bardzo gorąca wiadomość (2012, styczeń)

W przypadku nietrywialnych aplikacji korporacyjnych opartych na bazie danych naprawdę nie ma usprawiedliwienia dla nieużywania ORM.

Oprócz funkcji:

• Nie używając ORM, rozwiązujesz problem, który był już wielokrotnie rozwiązywany przez duże społeczności lub firmy dysponujące znacznymi zasobami.
• Korzystając z ORM, rdzeń warstwy dostępu do danych czerpie korzyści z debugowania tej społeczności lub firmy.

Aby przedstawić argument z pewnej perspektywy, rozważ korzyści wynikające z używania ADO.NET w porównaniu z samodzielnym pisaniem kodu w celu przeanalizowania strumienia danych tabelarycznych.

Widziałem nieznajomość tego, jak używać ORMów, uzasadniając pogardę dewelopera dla ORMów. Na przykład: chętne ładowanie (zauważyłem, że nie wspomniałeś). Wyobraź sobie, że chcesz pobrać klienta i wszystkie jego zamówienia, a dla nich wszystkie szczegóły zamówienia. Jeśli polegasz tylko na leniwym ładowaniu, odejdziesz od doświadczenia z ORM z opinią: „ORMy są powolne”. Jeśli nauczysz się, jak korzystać z szybkiego ładowania, w ciągu 2 minut z 5 wierszami kodu zrobisz to, co Twoi koledzy zajmie pół dnia, aby zaimplementować: jedno zapytanie do bazy danych i powiązanie wyników z hierarchią obiektów. Innym przykładem może być ból związany z ręcznym pisaniem zapytań SQL w celu implementacji stronicowania.

Możliwym wyjątkiem od korzystania z ORM byłoby, gdyby ta aplikacja była strukturą ORM zaprojektowaną do stosowania wyspecjalizowanych abstrakcji logiki biznesowej i zaprojektowaną do ponownego wykorzystania w wielu projektach. Jednak nawet w takim przypadku przyspieszyłbyś adopcję, ulepszając istniejący ORM o te abstrakcje.

Nie pozwól, aby doświadczenie starszych członków zespołu ciągnęło Cię w przeciwnym kierunku ewolucji informatyki. Od 23 lat rozwijam się zawodowo, a jedną ze stałych jest pogarda starej szkoły dla nowego. ORMy są do SQL tak, jak język C był w asemblerze, i możesz się założyć, że odpowiedniki C ++ i C # są w drodze. Jedna linia kodu nowej szkoły to 20 linii kodu starej szkoły.

Myślę, że może podczas pracy na większych systemach zamiast ORM można użyć narzędzia do generowania kodu, takiego jak CodeSmith ... Niedawno znalazłem to: Cooperator Framework, który generuje procedury składowane SQL Server, a także generuje twoje jednostki biznesowe, mapery, bramy, lazyload i wszystkie te rzeczy w C # ... zobacz to ... zostało napisane przez zespół tutaj w Argentynie ...

Myślę, że jest to pośrodku między zakodowaniem całej warstwy dostępu do danych a użyciem ORM ...

Osobiście (do niedawna) sprzeciwiam się używaniu ORM i zwykłem radzić sobie z pisaniem warstwy dostępu do danych zawierającej wszystkie polecenia SQL. Głównym zarzutem wobec ORMów było to, że nie ufałem implementacji ORM, aby napisać dokładnie poprawny SQL. Sądząc po ORMach, które widziałem (głównie biblioteki PHP), myślę, że miałem całkowitą rację.

Teraz większość mojego tworzenia stron internetowych korzysta z Django i uważam, że dołączony ORM jest naprawdę wygodny, a ponieważ model danych jest najpierw wyrażany w ich terminach, a dopiero później w SQL, działa idealnie dla moich potrzeb. Jestem pewien, że nie byłoby zbyt trudno go przerosnąć i uzupełnić ręcznie napisanym SQL; ale dostęp CRUD jest więcej niż wystarczający.

Nie wiem o NHibernate; ale wydaje mi się, że jest również „wystarczająco dobry” do większości potrzebnych Ci rzeczy. Ale jeśli inni programiści mu nie ufają; będzie głównym podejrzanym w przypadku każdego błędu związanego z danymi, przez co weryfikacja będzie bardziej uciążliwa.

Możesz spróbować wprowadzać to stopniowo w swoim miejscu pracy, skupiając się najpierw na małych „oczywistych” aplikacjach, takich jak prosty dostęp do danych. Po jakimś czasie może być używany na prototypach i nie da się go zastąpić ...

Jeśli jest to baza danych OLAP (np. Statyczne dane tylko do odczytu używane do raportowania / analizy itp.), Implementacja struktury ORM nie jest odpowiednia. Zamiast tego preferowane byłoby korzystanie z natywnych funkcji dostępu do danych bazy danych, takich jak procedury składowane. ORMy są lepiej dostosowane do systemów transakcyjnych (OLTP).

Myślę, że jest wiele dobrych powodów, aby nie używać ORM. Przede wszystkim jestem programistą .NET i lubię trzymać się tego, co zapewnia mi wspaniały framework .NET. Robi wszystko, czego potrzebuję. Robiąc to, pozostajesz przy bardziej standardowym podejściu, a tym samym istnieje znacznie większa szansa, że ​​jakikolwiek inny programista pracujący nad tym samym projektem będzie w stanie odebrać to, co jest i uruchomić z tym. Możliwości dostępu do danych, które już zapewnia Microsoft, są dość duże, nie ma powodu, aby je odrzucać.

Jestem profesjonalnym programistą od 10 lat, prowadziłem wiele bardzo udanych projektów wartych ponad milion dolarów i ani razu nie napisałem aplikacji, która wymagałaby przełączenia się na dowolną bazę danych. Dlaczego miałbyś kiedykolwiek chcieć, aby klient to zrobił? Planuj uważnie, wybierz odpowiednią bazę danych dla tego, czego potrzebujesz i trzymaj się jej. Osobiście SQL Server był w stanie zrobić wszystko, czego kiedykolwiek potrzebowałem. To proste i działa świetnie. Dostępna jest nawet bezpłatna wersja, która obsługuje do 10 GB danych. Aha, i działa świetnie z .NET.

Niedawno musiałem rozpocząć pracę nad kilkoma projektami, które używają ORM jako warstwy danych. Myślę, że to jest złe i coś dodatkowego, czego musiałem się nauczyć bez żadnego powodu. W niesamowicie rzadkich okolicznościach, gdy klient musiał zmienić bazy danych, mogłem z łatwością przerobić całą warstwę danych w krótszym czasie niż spędziłem na oszukiwaniu dostawców ORM.

Szczerze mówiąc, myślę, że ORM ma jedno prawdziwe zastosowanie: jeśli tworzysz aplikację taką jak SAP, która naprawdę potrzebuje możliwości działania na wielu bazach danych. W przeciwnym razie, jako dostawca rozwiązań, mówię moim klientom, że ta aplikacja jest zaprojektowana do działania w tej bazie danych i tak właśnie jest. Po raz kolejny, po 10 latach i niezliczonej liczbie zgłoszeń, nigdy nie był to problem.

W przeciwnym razie myślę, że ORMy są dla programistów, którzy nie rozumieją, że mniej znaczy więcej i myślę, że im więcej fajnych narzędzi innych firm używają w swojej aplikacji, tym lepsza będzie ich aplikacja. Zostawię takie rzeczy zagorzałym maniakom ubera, podczas gdy w międzyczasie stworzę znacznie więcej świetnego oprogramowania, które każdy programista może odebrać i od razu zacząć produktywność.

Wydajność w czasie rzeczywistym to jedyny prawdziwy minus, o jakim przychodzi mi do głowy, ale myślę, że to więcej niż uczciwy kompromis za czas, który ORM oszczędza podczas tworzenia / testowania / itp. W większości przypadków powinieneś być w stanie zlokalizować wąskie gardła danych i zmienić struktury obiektów, aby były bardziej wydajne.

Nie korzystałem wcześniej z Hibernate'a, ale jedną rzeczą, którą zauważyłem w przypadku kilku „gotowych” rozwiązań ORM, jest brak elastyczności. Jestem pewien, że zależy to od tego, z czym idziesz i co musisz z tym zrobić.

Istnieją dwa aspekty ORM, które są niepokojące. Po pierwsze, są to kod napisany przez kogoś innego, czasami z zamkniętym kodem, czasami z otwartym kodem źródłowym, ale o ogromnym zakresie. Po drugie, kopiują dane.

Pierwszy problem powoduje dwa problemy. Polegasz na kodzie z zewnątrz. Wszyscy to robimy, ale nie należy lekceważyć wyboru. A co, jeśli nie zrobi tego, czego potrzebujesz? Kiedy to odkryjesz? Żyjesz w pudełku, które rysuje dla ciebie ORM.

Drugi problem dotyczy zatwierdzania dwufazowego. Relacyjna baza danych jest kopiowana do modelu obiektowego. Zmieniasz model obiektowy i ma on aktualizować bazę danych. To jest zatwierdzanie dwufazowe i nie jest najłatwiejsze do debugowania.

Proponuję tę lekturę, aby uzyskać listę wad ORMów.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Osobiście uważam, że ORMy są bardzo przydatne w większości napisanych przeze mnie aplikacji!

/ Asger

Doświadczenie, które miałem z Hibernate, polega na tym, że jego semantyka jest subtelna, a kiedy pojawiają się problemy, trochę trudno jest zrozumieć, co się dzieje pod maską. Słyszałem od znajomego, że często zaczyna się od Criteria, potem potrzebuje trochę większej elastyczności i potrzebuje HQL, a później zauważam, że w końcu potrzebny jest surowy SQL (na przykład Hibernate nie ma związku AFAIK).

Również w przypadku ORM ludzie łatwo mają tendencję do nadużywania istniejących mapowań / modeli, co prowadzi do tego, że istnieje obiekt z wieloma atrybutami, które nie są zainicjowane. Więc po zapytaniu, wewnątrz transakcji Hibernate pobiera dodatkowe dane, co prowadzi do potencjalnego spowolnienia. Niestety, obiekt modelu hibernacji czasami wycieka do warstwy architektury widoku, a następnie widzimy LazyInitializationExceptions.

Aby używać ORM, należy to naprawdę zrozumieć. Niestety łatwo odnieść wrażenie, że jest łatwo, a nie jest.

Żeby nie być odpowiedzią per se, chcę przeformułować cytat, który ostatnio słyszałem. „Dobry ORM jest jak Yeti, wszyscy o nim mówią, ale nikt tego nie widzi”.

Za każdym razem, gdy kładę ręce na ORM, zwykle zmagam się z problemami / ograniczeniami tego ORM. W końcu tak, robi to, co chcę i zostało to zapisane gdzieś w tej kiepskiej dokumentacji, ale tracę kolejną godzinę, której nigdy nie dostanę. Każdy, kto używał nhibernate, a potem płynnie nhibernate na postgresql, zrozumiałby, przez co przeszedłem. Ciągłe uczucie, że „ten kod nie jest pod moją kontrolą” jest do niczego.

Nie wskazuję palcami ani nie mówię, że są złe, ale zacząłem myśleć o tym, co rozdaję tylko po to, aby zautomatyzować CRUD w jednym wyrażeniu. W dzisiejszych czasach myślę, że powinienem mniej korzystać z ORMów, być może stworzyć lub znaleźć rozwiązanie, które zapewni minimum operacji db. Ale to tylko ja. Wierzę, że niektóre rzeczy są nie tak na tej arenie ORM, ale nie mam wystarczających umiejętności, aby wyrazić to, co nie.

Myślę, że użycie ORM jest nadal dobrym pomysłem. Zwłaszcza biorąc pod uwagę sytuację, którą dajesz. Z twojego postu wydaje się, że jesteś bardziej doświadczony, jeśli chodzi o strategie dostępu do bazy danych, a ja poruszyłbym kwestię korzystania z ORM.

Nie ma argumentu za numerem 1, ponieważ kopiowanie i wklejanie zapytań oraz zakodowanie na stałe w tekście nie daje żadnej elastyczności, a dla # 2 większość ormów zawija oryginalny wyjątek, pozwala na śledzenie wygenerowanych zapytań itp., Więc debugowanie również nie jest fizyką rakietową.

Jeśli chodzi o walidację, użycie ORM zwykle pozwala również znacznie łatwiej opracować strategie walidacji, poza wszelkimi wbudowanymi walidacjami.

Pisanie własnego frameworka może być pracochłonne i często coś jest pomijane.

EDYCJA: chciałem poruszyć jeszcze jedną kwestię. Jeśli Twoja firma przyjmie strategię ORM, która jeszcze bardziej zwiększy jej wartość, ponieważ opracujesz wytyczne i praktyki dotyczące stosowania i wdrażania, a wszyscy będą dalej poszerzać swoją wiedzę na temat wybranej struktury, łagodząc jeden z problemów, które poruszyłeś. Dowiesz się również, co działa, a co nie, gdy zaistnieją sytuacje, a na koniec zaoszczędzi to mnóstwo czasu i wysiłku.

Każdy ORM, nawet „dobry”, jest obarczony pewną liczbą założeń związanych z podstawową mechaniką używaną przez oprogramowanie do przekazywania danych między warstwą aplikacji a magazynem danych.

Zauważyłem, że w przypadku średnio wyrafinowanych aplikacji obejście tych założeń zajmuje mi zwykle więcej czasu niż zwykłe napisanie prostszego rozwiązania, takiego jak: przeszukiwanie danych i ręczne tworzenie instancji nowych jednostek.

W szczególności prawdopodobnie napotkasz problemy, gdy tylko zastosujesz klucze wielokolumnowe lub inne umiarkowanie złożone relacje, które wykraczają poza zakres przydatnych przykładów, które dostarczył ci ORM podczas pobierania kodu.

Przyznaję, że dla niektórych typów aplikacji, szczególnie tych, które mają bardzo dużą liczbę tabel bazy danych lub dynamicznie generowanych tabel bazy danych, może być przydatny proces auto-magii ORM.

W przeciwnym razie do diabła z ORMami. Teraz uważam je za modę.