powinieneś zrobić z niej wiki, jeśli chcesz ankietę
frankodwyer
+1 za uczynienie z niej wiki, jeśli chcesz ankietę
cletus
16
A co z oszustwami?
Brian Matthews
4
I bez łyżki. Nie, naprawdę, jest wada: wydajność. O wiele łatwiej jest zoptymalizować zapytania DB, gdy nie musisz przechodzić przez ORM. (Nie narzekam - niedawno przesiadłem się na ORM, jestem z niego głównie zadowolony; do ogólnego celu ORM jest drogą do zrobienia; ale zachowaj sposób, aby wykonywać zapytania bliżej metalu, jeśli potrzebujesz wydajności)
Piskvor opuścił budynek
2
@ UğurGümüşhan, IMHO Główną zaletą korzystania z ORM jest zwiększenie produktywności programistów, pozwalając im programować w tym samym języku i paradygmacie OO, których używają w pozostałej części aplikacji. Procedury składowane nie mogą tego zapewnić, gdy tworzą kod programisty w języku procedur składowanych RDBMS. Więc nie mogą zrobić wszystkiego, co może ORM.
Bill Karwin,
Odpowiedzi:
53
Bardziej abstrakcyjny i przenośny dostęp do danych. Klasy implementacyjne ORM potrafią pisać SQL specyficzny dla dostawcy, więc nie musisz tego robić.
Chociaż zgadzam się, że jest to cecha ORMów, proponuję, aby przypadek użycia był dość ograniczony. Nigdy nie korzystałem z niczego poza MySql i sqlite przez około dekadę. Myślę, że jest to prawdopodobnie bardzo rzadki wymóg dla większości programistów.
troelskn
40
@troelskn: Zgadzam się, używałem wielu produktów RDBMS, ale nigdy więcej niż jednego lub dwóch na projekt. Tak więc przenośność nie jest najbardziej praktyczną wartością abstrakcji SQL. Myślę, że wielu użytkowników ORM po prostu chce w ogóle uniknąć kodowania w SQL.
Bill Karwin,
2
dostawcy cały czas pojawiają się z nowymi wersjami / funkcjami ... po prostu potrzebują fajnych ludzi do pisania dialektu i łatwa aktualizacja!
dotjoe
5
Typowa bezużyteczna odpowiedź Zastanawiam się, dlaczego jest oznaczona jako dobra odpowiedź, wygląda na to, że facet, który zadaje pytanie, po prostu próbuje uzasadnić swojemu szefowi, że powinien użyć ORMa :) Moje pytanie raczej dotyczy tego, jaki problem napotkasz z Hibernate stackoverflow.com/questions/6477170/…
user310291
2
@ user310291: OP nie pytał o problemy ani pułapki, poprosił o korzyści wynikające z używania ORM. Oczywiście są plusy i minusy, ale poprosił o plusy. Szczerze mówiąc, jestem zaskoczony, że ta odpowiedź została zaakceptowana i otrzymała tyle samo pozytywnych głosów, co, ponieważ nie zaliczyłbym tego jako głównej korzyści z ORM.
Bill Karwin,
83
Najważniejszym powodem używania ORM jest to, że możesz mieć bogaty, zorientowany obiektowo model biznesowy, a jednocześnie móc go przechowywać i szybko pisać efektywne zapytania w relacyjnej bazie danych. Z mojego punktu widzenia nie widzę żadnych rzeczywistych korzyści, jakie daje dobry ORM w porównaniu z innymi generowanymi DAL innymi niż zaawansowane typy zapytań, które możesz napisać.
Jeden rodzaj zapytania, o którym myślę, to zapytanie polimorficzne. Proste zapytanie ORM może wybrać wszystkie kształty w bazie danych. Otrzymujesz z powrotem kolekcję kształtów. Ale każda instancja jest kwadratem, okręgiem lub prostokątem w zależności od swojego dyskryminatora.
Innym typem zapytania byłoby takie, które chętnie pobiera obiekt i jeden lub więcej powiązanych obiektów lub kolekcji w jednym wywołaniu bazy danych. Np. każdy obiekt kształtu jest zwracany z wypełnionymi zbiorami wierzchołków i boków.
Przykro mi, że nie zgadzam się z tak wieloma innymi tutaj, ale nie sądzę, że generowanie kodu samo w sobie jest wystarczającym powodem, aby korzystać z ORM. Możesz napisać lub znaleźć wiele dobrych szablonów DAL dla generatorów kodu, które nie mają narzutu koncepcyjnego lub wydajnościowego, jak w przypadku ORM.
Lub, jeśli myślisz, że nie musisz umieć pisać dobrego SQL, aby używać ORM, znowu się z tym nie zgadzam. Może być prawdą, że z perspektywy pisania pojedynczych zapytań poleganie na ORM jest łatwiejsze. Ale w przypadku ORM zbyt łatwo jest tworzyć procedury o niskiej wydajności, gdy programiści nie rozumieją, jak ich zapytania działają z ORM i SQL, na które tłumaczą.
Posiadanie warstwy danych, która działa z wieloma bazami danych, może być zaletą. Jednak nie jest to jeden, na którym musiałem często polegać.
Na koniec muszę powtórzyć, że z mojego doświadczenia wynika, że jeśli nie używasz bardziej zaawansowanych funkcji zapytań swojego ORM, istnieją inne opcje, które rozwiązują pozostałe problemy przy mniejszej liczbie uczenia się i mniejszej liczbie cykli procesora.
O tak, niektórzy programiści uważają, że praca z ORMami jest fajna, więc ORMy są również dobre z punktu widzenia utrzymania zadowolenia programistów. =)
Dobrze powiedziane. Podczas gdy oryginalny plakat szukał w szczególności „zalet”, a nie „wad”, widziałem STRASZNY SQL utworzony przez niezrozumienie wpływu JAK używasz ORM. Dla mnie największą korzyścią są proste transakcje CRUD, które stanowią większość twojego kodu DAL dla systemów transakcyjnych. Myślę, że dzielisz włosy na czysty ORM i inne wygenerowane metody DAL. Myślę, że wszystko, co pomaga w tłumaczeniu między obiektami a bazą danych, można uznać za ORM, to po prostu inny model operacyjny.
Doug Lampe
1
@Doug - Myślę, że rozróżnienie, o które mi chodziło, polegało na tym, że prosty DAL składał się z niewiele więcej niż wygenerowanego CRUD SQL, podczas gdy ORM zawierał o wiele więcej abstrakcji, takich jak właściwości nawigacji, trwałość kolekcji, dedykowane języki zapytań, pamięci podręczne itp. - Lepszy sposób w świetle twoich obserwacji może być takie, że chociaż prawdą jest, że korzystanie z większej liczby funkcji ORM pozwala na szybszą implementację, nie jest dopuszczalne ignorowanie tego, jak działają te funkcje. Być może dlatego, że abstrakcje ORMów wyciekają bardziej niż większość. ( En.wikipedia.org/wiki/Leaky_abstraction )
Chuck
proszę o rozwinięcie tego bardziej szczegółowo: „jeśli nie używasz bardziej zaawansowanych funkcji zapytań w ORM, istnieją inne opcje, które rozwiązują pozostałe problemy”. również, jak mówi twórca hibernacji Gavin King: „Rzeczywiście, systemy takie jak Hibernate są celowo projektowane jako„ nieszczelne abstrakcje ”, aby w razie potrzeby można było łatwo mieszać natywny SQL. Nieszczelność abstrakcji ORM jest cechą, a nie błędem ! ” - reddit.com/r/programming/comments/2cnw8x/…
jungle_mole
1) To jest stare. W tamtych czasach ORMy posiadały wszystkie funkcje (pamięci podręczne, zapytania, przetwarzanie wsadowe itp.). IMHO, oparte na obiektach, polimorficzne zapytania były jedyną cechą ORM, której gen kodu (jawne mapowanie ADO) nie mógł łatwo zapewnić. 2) Podczas gdy kilka przydatnych dziur zostało celowo pozostawionych, istniało również konieczne zło i zaawansowane funkcje, które stworzyły dużą krzywą uczenia się w ORMach. Tak więc moją odpowiedzią było użycie genów kodu zamiast ORMów, chyba że potrzebujesz zaawansowanych zapytań. *) Obecnie istnieje wystarczająca różnorodność ORMów, że prawdopodobnie istnieje odpowiedni zestaw funkcji dla Twojego zespołu. Mój zespół lubi teraz Linq2DB.
Chuck
60
Przyspieszenie rozwoju. Na przykład wyeliminowanie powtarzającego się kodu, takiego jak mapowanie pól wyników zapytania na elementy składowe obiektu i odwrotnie.
Powtarzający się kod jest bardzo zły, ale czy nie mógłbyś zbudować abstrakcji, która by to usunęła? Na przykład możesz mieć obiekt tabeli / wyników zapytania, który dostarczy ci wiersze, z którymi możesz następnie wykonywać różne czynności. Wydaje się, że ORMy dzielą wiersze na poszczególne instancje klas, zamiast wchodzić do wybranej abstrakcji bazy danych, czyli tabel / wierszy wyników zapytań. Nie mówię, że oznacza to, że ORM nie są dobre, ale nie jestem pewien, czy samo to jest powodem ich używania.
Benjohn
@Benjohn, zgadzam się, że rozwiązanie ORM traktuje pojedyncze wiersze jako obiekty, podczas gdy RDBMS traktuje zestawy wierszy jako całość. Są rzeczy, które możesz zrobić w nastawieniu RDBMS, a których nie możesz zrobić w nastawieniu OO.
Bill Karwin
To tak, jakby kupować cały samochód tylko po to, by korzystać z bagażnika, jest wiele sposobów na uniknięcie powtarzalnej pracy
mohe
15
Obsługa enkapsulacji OO reguł biznesowych w warstwie dostępu do danych. Możesz pisać (i debugować) reguły biznesowe w preferowanym języku aplikacji, zamiast niezgrabnych wyzwalaczy i języków procedur składowanych.
Nie chcesz jednak mieć swoich reguł biznesowych w bazie danych? To jest zaleta bazy danych, prawda: wielu klientów może używać tego samego interfejsu dostarczanego przez DBMS. Jeśli duża część logiki interfejsu jest zablokowana w kodzie ORM konkretnego klienta, nie ma jej w bazie danych, a inni klienci jej nie używają. Cue front office przerwy w biurze (model jednego klienta wymyka się kolejce od innego).
Benjohn
1
@Benjohn, mam tendencję do umieszczania w bazie danych prostych reguł biznesowych, ale bardziej złożone reguły nie są łatwe do utworzenia w ograniczeniach deklaratywnych. Np. „Klient otrzymuje 10% rabatu na całe zamówienie przy pierwszym zakupie więcej niż trzech par spodni tej samej marki”. Jak umieścić tę regułę biznesową w bazie danych (pamiętaj, że odpowiedź dotycząca procedur składowanych jest niezgrabna).
Bill Karwin
Jest rok 2020, nie widzę już nikogo używającego procedur składowanych. Więc czy wskazujesz nadal stoi?
ospider
Myślę, że chodzi mi o to, że ludzie nie używają procedur składowanych, używają kodu aplikacji. Czy zrozumiałeś coś innego?
Bill Karwin
10
Generowanie kodu standardowego dla podstawowych operacji CRUD. Niektóre struktury ORM mogą bezpośrednio sprawdzać metadane bazy danych, odczytywać pliki mapowania metadanych lub używać deklaratywnych właściwości klas.
Przez ponad 30 lat pracy w bazie danych ani razu nie musiałem tego robić.
HLGEM
4
To nie znaczy, że to niemożliwe! :)
Matt Fenelon
2
@HLGEM oznacza to, że zamykasz wybory dla klienta. To może się faktycznie zdarzyć, w ciągu zaledwie 3 lat pracy nad aplikacjami internetowymi stworzyliśmy przenośne oprogramowanie przy użyciu
ORMów
1
Może ci się to przydać, jeśli chcesz przeprowadzić testy na bazie danych w pamięci
Carlos Parraga
Możliwe, że kilka wystąpień tego samego oprogramowania może korzystać z różnych baz danych. Jednak przenoszenie istniejących danych z jednego oprogramowania DB do innego jest naprawdę rzadkie. A kiedy tak się dzieje, wiele ORMów w rzeczywistości ci w tym nie pomaga.
jlh
4
Aby model obiektowy i model trwałości były zgodne.
Może dlatego, że twoja trwałość jest przezroczysta dla twojego modelu obiektowego
S.Lott
4
Rozwój szczęścia, IMO. ORM usuwa wiele podstawowych rzeczy, które musisz wykonać w SQL. Utrzymuje prostą bazę kodu: mniej plików źródłowych do zarządzania, a zmiany schematów nie wymagają godzin utrzymania.
Powodem, dla którego się tym zajmuję, jest uniknięcie wygenerowanego kodu z narzędzi DAL VS2005 (mapowanie schematu, TableAdapters).
DAL / BLL, który utworzyłem ponad rok temu, działał dobrze (do tego, do czego go zbudowałem), dopóki ktoś inny nie zaczął go używać do korzystania z niektórych wygenerowanych funkcji (o których nie miałem pojęcia)
Wygląda na to, że zapewni znacznie bardziej intuicyjne i czystsze rozwiązanie niż rozwiązanie DAL / BLL ze strony http://wwww.asp.net
Myślałem o stworzeniu własnego generatora kodu SQL Command C # DAL, ale ORM wygląda na bardziej eleganckie rozwiązanie
Wraz z ulepszaniem narzędzi ORM, łatwiej jest szybciej określić poprawność zapytań dzięki błędom czasu kompilacji i testom.
Kompilowanie zapytań pomaga programistom szybciej znajdować błędy. Dobrze? Dobrze. Ta kompilacja jest możliwa, ponieważ programiści piszą teraz zapytania w kodzie przy użyciu ich obiektów biznesowych lub modeli zamiast tylko ciągów instrukcji SQL lub SQL.
Jeśli używasz poprawnych wzorców dostępu do danych w .NET, możesz łatwo przetestować logikę zapytań w kolekcjach pamięci. Przyspiesza to wykonywanie testów, ponieważ nie musisz uzyskiwać dostępu do bazy danych, konfigurować danych w bazie danych ani nawet uruchamiać pełnego kontekstu danych. [EDYCJA] To nie jest tak prawdziwe, jak myślałem, że to jednostka testowanie w pamięci może stanowić trudne wyzwanie do pokonania. Ale nadal uważam, że te testy integracji są łatwiejsze do napisania niż w poprzednich latach. [/ EDYCJA]
Jest to zdecydowanie bardziej istotne dzisiaj niż kilka lat temu, kiedy zadano to pytanie, ale może tak być tylko w przypadku Visual Studio i Entity Framework, w których leży moje doświadczenie. Jeśli to możliwe, podłącz własne środowisko.
Myślę, że jest tu wiele dobrych punktów (przenośność, łatwość rozwoju / utrzymania, skupienie się na modelowaniu biznesowym OO itp.), Ale kiedy próbujesz przekonać klienta lub kierownictwo, wszystko sprowadza się do tego, ile pieniędzy zaoszczędzisz, używając ORM .
Dokonaj szacunków dla typowych zadań (lub nawet większych projektów, które mogą się pojawić), a (miejmy nadzieję!) Uzyskasz kilka argumentów za przełączeniem, które trudno zignorować.
Fuj. Użyliśmy Net Tiers w dużym projekcie komercyjnym i zdecydowanie odradzałbym jego używanie. Problem w tym, że nie daje się komponować. Chcesz zapytać o obiekty Foo i Bar? Nie możesz pisać złączeń, musisz wydawać oddzielne zapytania dla każdego typu obiektu, który chcesz. Powoduje to wiele wywołań bazy danych, co może zepsuć wydajność i niepodzielność. Zły zły zły. Nie zbliżaj się.
Judah Gabriel Himango,
0
przekonaj ich, ile czasu / pieniędzy zaoszczędzisz, gdy pojawią się zmiany i nie musisz przepisywać kodu SQL, ponieważ narzędzie ORM zrobi to za Ciebie
Myślę, że jedną wadą jest to, że ORM będzie wymagał aktualizacji w twoim POJO. głównie związane ze schematem, relacją i zapytaniem. więc scenariusz, w którym nie przewiduje się wprowadzania zmian w obiektach modelu, może być spowodowany tym, że jest on współdzielony między innymi na kliencie projektu lub czarno-białym i serwerze. więc w takich przypadkach będziesz musiał podzielić go na dwa poziomy, co będzie wymagało dodatkowych wysiłków.
Jestem programistą Androida i, jak wiesz, aplikacje mobilne zwykle nie są duże, więc ten dodatkowy wysiłek w celu oddzielenia modelu czystego i modelu dotkniętego orm nie wydaje się być w pełni opłacalny.
Rozumiem, że to pytanie ogólne. ale aplikacje mobilne są również objęte ogólnym parasolem.
Odpowiedzi:
Bardziej abstrakcyjny i przenośny dostęp do danych. Klasy implementacyjne ORM potrafią pisać SQL specyficzny dla dostawcy, więc nie musisz tego robić.
źródło
Najważniejszym powodem używania ORM jest to, że możesz mieć bogaty, zorientowany obiektowo model biznesowy, a jednocześnie móc go przechowywać i szybko pisać efektywne zapytania w relacyjnej bazie danych. Z mojego punktu widzenia nie widzę żadnych rzeczywistych korzyści, jakie daje dobry ORM w porównaniu z innymi generowanymi DAL innymi niż zaawansowane typy zapytań, które możesz napisać.
Jeden rodzaj zapytania, o którym myślę, to zapytanie polimorficzne. Proste zapytanie ORM może wybrać wszystkie kształty w bazie danych. Otrzymujesz z powrotem kolekcję kształtów. Ale każda instancja jest kwadratem, okręgiem lub prostokątem w zależności od swojego dyskryminatora.
Innym typem zapytania byłoby takie, które chętnie pobiera obiekt i jeden lub więcej powiązanych obiektów lub kolekcji w jednym wywołaniu bazy danych. Np. każdy obiekt kształtu jest zwracany z wypełnionymi zbiorami wierzchołków i boków.
Przykro mi, że nie zgadzam się z tak wieloma innymi tutaj, ale nie sądzę, że generowanie kodu samo w sobie jest wystarczającym powodem, aby korzystać z ORM. Możesz napisać lub znaleźć wiele dobrych szablonów DAL dla generatorów kodu, które nie mają narzutu koncepcyjnego lub wydajnościowego, jak w przypadku ORM.
Lub, jeśli myślisz, że nie musisz umieć pisać dobrego SQL, aby używać ORM, znowu się z tym nie zgadzam. Może być prawdą, że z perspektywy pisania pojedynczych zapytań poleganie na ORM jest łatwiejsze. Ale w przypadku ORM zbyt łatwo jest tworzyć procedury o niskiej wydajności, gdy programiści nie rozumieją, jak ich zapytania działają z ORM i SQL, na które tłumaczą.
Posiadanie warstwy danych, która działa z wieloma bazami danych, może być zaletą. Jednak nie jest to jeden, na którym musiałem często polegać.
Na koniec muszę powtórzyć, że z mojego doświadczenia wynika, że jeśli nie używasz bardziej zaawansowanych funkcji zapytań swojego ORM, istnieją inne opcje, które rozwiązują pozostałe problemy przy mniejszej liczbie uczenia się i mniejszej liczbie cykli procesora.
O tak, niektórzy programiści uważają, że praca z ORMami jest fajna, więc ORMy są również dobre z punktu widzenia utrzymania zadowolenia programistów. =)
źródło
Przyspieszenie rozwoju. Na przykład wyeliminowanie powtarzającego się kodu, takiego jak mapowanie pól wyników zapytania na elementy składowe obiektu i odwrotnie.
źródło
Obsługa enkapsulacji OO reguł biznesowych w warstwie dostępu do danych. Możesz pisać (i debugować) reguły biznesowe w preferowanym języku aplikacji, zamiast niezgrabnych wyzwalaczy i języków procedur składowanych.
źródło
Generowanie kodu standardowego dla podstawowych operacji CRUD. Niektóre struktury ORM mogą bezpośrednio sprawdzać metadane bazy danych, odczytywać pliki mapowania metadanych lub używać deklaratywnych właściwości klas.
źródło
Możesz łatwo przejść do innego oprogramowania bazy danych, ponieważ tworzysz abstrakcję.
źródło
Aby model obiektowy i model trwałości były zgodne.
źródło
Rozwój szczęścia, IMO. ORM usuwa wiele podstawowych rzeczy, które musisz wykonać w SQL. Utrzymuje prostą bazę kodu: mniej plików źródłowych do zarządzania, a zmiany schematów nie wymagają godzin utrzymania.
Obecnie używam ORM i przyspieszyło to mój rozwój.
źródło
Aby zminimalizować powielanie prostych zapytań SQL.
źródło
Powodem, dla którego się tym zajmuję, jest uniknięcie wygenerowanego kodu z narzędzi DAL VS2005 (mapowanie schematu, TableAdapters).
DAL / BLL, który utworzyłem ponad rok temu, działał dobrze (do tego, do czego go zbudowałem), dopóki ktoś inny nie zaczął go używać do korzystania z niektórych wygenerowanych funkcji (o których nie miałem pojęcia)
Wygląda na to, że zapewni znacznie bardziej intuicyjne i czystsze rozwiązanie niż rozwiązanie DAL / BLL ze strony http://wwww.asp.net
Myślałem o stworzeniu własnego generatora kodu SQL Command C # DAL, ale ORM wygląda na bardziej eleganckie rozwiązanie
źródło
Kompilacja i testowanie zapytań.
Wraz z ulepszaniem narzędzi ORM, łatwiej jest szybciej określić poprawność zapytań dzięki błędom czasu kompilacji i testom.
Kompilowanie zapytań pomaga programistom szybciej znajdować błędy. Dobrze? Dobrze. Ta kompilacja jest możliwa, ponieważ programiści piszą teraz zapytania w kodzie przy użyciu ich obiektów biznesowych lub modeli zamiast tylko ciągów instrukcji SQL lub SQL.
Jeśli używasz poprawnych wzorców dostępu do danych w .NET, możesz łatwo przetestować logikę zapytań w kolekcjach pamięci. Przyspiesza to wykonywanie testów, ponieważ nie musisz uzyskiwać dostępu do bazy danych, konfigurować danych w bazie danych ani nawet uruchamiać pełnego kontekstu danych. [EDYCJA] To nie jest tak prawdziwe, jak myślałem, że to jednostka testowanie w pamięci może stanowić trudne wyzwanie do pokonania. Ale nadal uważam, że te testy integracji są łatwiejsze do napisania niż w poprzednich latach. [/ EDYCJA]
Jest to zdecydowanie bardziej istotne dzisiaj niż kilka lat temu, kiedy zadano to pytanie, ale może tak być tylko w przypadku Visual Studio i Entity Framework, w których leży moje doświadczenie. Jeśli to możliwe, podłącz własne środowisko.
źródło
Abstrakcja sql away 95% czasu, więc nie każdy w zespole musi wiedzieć, jak pisać bardzo wydajne zapytania specyficzne dla bazy danych.
źródło
Myślę, że jest tu wiele dobrych punktów (przenośność, łatwość rozwoju / utrzymania, skupienie się na modelowaniu biznesowym OO itp.), Ale kiedy próbujesz przekonać klienta lub kierownictwo, wszystko sprowadza się do tego, ile pieniędzy zaoszczędzisz, używając ORM .
Dokonaj szacunków dla typowych zadań (lub nawet większych projektów, które mogą się pojawić), a (miejmy nadzieję!) Uzyskasz kilka argumentów za przełączeniem, które trudno zignorować.
źródło
.net tiers przy użyciu szablonów Code Smith
http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1
Po co kodować coś, co można równie dobrze wygenerować.
źródło
przekonaj ich, ile czasu / pieniędzy zaoszczędzisz, gdy pojawią się zmiany i nie musisz przepisywać kodu SQL, ponieważ narzędzie ORM zrobi to za Ciebie
źródło
Myślę, że jedną wadą jest to, że ORM będzie wymagał aktualizacji w twoim POJO. głównie związane ze schematem, relacją i zapytaniem. więc scenariusz, w którym nie przewiduje się wprowadzania zmian w obiektach modelu, może być spowodowany tym, że jest on współdzielony między innymi na kliencie projektu lub czarno-białym i serwerze. więc w takich przypadkach będziesz musiał podzielić go na dwa poziomy, co będzie wymagało dodatkowych wysiłków.
Jestem programistą Androida i, jak wiesz, aplikacje mobilne zwykle nie są duże, więc ten dodatkowy wysiłek w celu oddzielenia modelu czystego i modelu dotkniętego orm nie wydaje się być w pełni opłacalny.
Rozumiem, że to pytanie ogólne. ale aplikacje mobilne są również objęte ogólnym parasolem.
źródło