Jakie projekty programistyczne korzystają z ORM?

10

Zacznę od stwierdzenia, że 95% mojej bazy danych wykonałem przy użyciu SQL. Ostatnio przeprowadziłem dochodzenie w sprawie różnych ORM, takich jak NHibernate i Doctrine.

Widzę zalety braku konieczności znajomości SQL i przenośności bazy danych, którą zapewnia ORM. Widzę jednak, że znajomość SQL sprawi, że praca z ORM będzie bardziej efektywna, i mogę pomyśleć tylko raz w mojej karierze, że największą zmianą aplikacji byłby dostawca bazy danych.

Ponieważ bardzo wygodnie piszę SQL i najwyraźniej nie zdaję sobie sprawy z często uczonych korzyści płynących z używania ORM, moje pytanie do dużych użytkowników ORM brzmi:

Jakie projekty programistyczne najbardziej przynoszą ORM?

— Fred Wilson
źródło

3

Odpowiedź brzmi: „Wszyscy”. Ale prawdopodobnie nie to chcesz wiedzieć. Możesz sprecyzować swoje pytanie, aby uzyskać bardziej szczegółowe informacje.

— S.Lott,

1

Dla mnie SQL jest obecnie łatwiejszy do wytworzenia, ale dzieje się tak tylko z powodu mojej aklimatyzacji (lub ignorancji). Czytałem, że ORM nie zawsze jest najlepszym wyborem, ponieważ jest wolniejszy niż normalny SQL; jednak wielu programistów stwierdziło, że zwykle nie jest to ważne. Najbardziej interesują mnie projekty, które najlepiej pasują do ORM. Widzę, że większość odpowiedzi to prawdopodobnie „wszystkie”, i to też jest w porządku. Nie szukam konkretnej odpowiedzi. :)

— Fred Wilson,

Jeśli nie poprosisz o więcej szczegółów, nie nauczysz się wiele.

— S.Lott,

5

(Niemal) wszystkie aplikacje korzystają z ORM.

Po pierwsze, nie zgadzam się z zaletami, które wymieniasz dla ORM .

Korzystanie z ORM niekoniecznie oznacza, że nie musisz znać SQL. Znajomość SQL pomoże zrozumieć, co faktycznie robi narzędzie ORM, co jest szczególnie przydatne podczas debugowania. Ponadto SQL może być faktycznie wymagany do opracowania złożonych zapytań, które są poza możliwościami wybranej przez ciebie ORM.
I jak mówisz, przenośność rzadko stanowi problem w prawdziwym życiu.

Zamiast tego prawdziwymi zaletami ORM są:

ORM oszczędza czas programisty, ponieważ oszczędza pisania ton logiki CRUD w SQL
wiele ORM zawiera złożoną logikę buforowania itp., która jest trudna do napisania i debugowania. Oprócz oszczędności czasu może to zwiększyć niezawodność i łatwość konserwacji aplikacji (lub przynajmniej zaoszczędzić czas potrzebny do osiągnięcia tych samych rezultatów)
najlepsze ORM mają społeczność użytkowników, którzy aktywnie rozwijają, utrzymują i wspierają produkt. Społeczność wokół niestandardowego SQL jest w najlepszym wypadku nieco mniej skoncentrowana na problemach, które musimy rozwiązać.

Jak komentujesz, jedną wadą ORM jest utrata wydajności. Zwykle można to jednak zrównoważyć, wydając więcej sprzętu.

Zazwyczaj czas programisty jest droższy niż sprzęt, więc ORM jest ogólnie dobrą opcją zamiast ręcznego kodowania SQL.

ORM najlepiej sprawdza się w aplikacjach z dużą ilością logiki baz danych CRUD. ORM jest mniej skuteczny w przypadku :

Aplikacje, które wymagają niewielkiego dostępu do bazy danych lub nie wymagają go wcale.
Aplikacje w dużym stopniu zależne od złożonych zapytań i bardzo małej prostej logiki CRUD
Sytuacje, w których wydajność ma krytyczne znaczenie, ale nie ma możliwości wdrożenia szybszego sprzętu

Z mojego doświadczenia wynika, że takie sytuacje są rzadkie. Stąd moja odpowiedź.

— Kramii
źródło

„Korzystanie z ORM niekoniecznie oznacza, że nie musisz znać SQL.” - Tak prawdziwe. Jedną z zalet, które widzę w środowisku zespołowym, jest to, że możemy skoncentrować zestaw umiejętności SQL, aby nie każdy programista pracujący na warstwie biznesowej musiał być ekspertem.

— Fred Wilson,

1

W przypadku złożonych zapytań zawsze możesz wrócić do SQL i napisać zapytanie SQL.

— harsimranb

4

Nie przeszkadza mi także pisanie SQL. Czuję się o wiele bardziej komfortowo, nie muszę w ogóle pisać SQL, a także nie martwię się o łączenie, rozłączanie, łączenie itp. Z bazą danych.

Więc .. Odpowiem na negatywne pytanie. Jedynymi projektami do tworzenia stron internetowych, które NIE korzystają z ORM, są te, które w ogóle nie rozmawiają z bazą danych. Które uważam za mniejszość (jeśli w ogóle).

— Otávio Décio
źródło

+1: Uważam się również za bardzo biegłego w sql, ale nadal wolę OR / M. W rzeczywistości powiedziałbym, że zdecydowanie musisz mieć uchwyt na sql, aby dobrze wykorzystać OR / M, w przeciwnym razie, gdy abstrakcja przecieka, nigdy nie znajdziesz problemu. „nie trzeba znać dużo SQL” nie jest funkcją. Dla mnie chodzi przede wszystkim o wzrost produktywności i sprawienie, by kompilator znalazł problemy, a nie środowisko uruchomieniowe i OR / M (szczególnie nowsze generics / linq są w tym świetne).

— Brook

@Brook - zgadzam się z całego serca. Użycie OR / M nie oznacza, że znajomość SQL jest opcjonalna.

— Otávio Décio

2

Opierając się na moim doświadczeniu z ASP.NET WebForms, sugerowałbym, że projekty internetowe wykorzystujące stanowe struktury sieciowe najbardziej korzystają z ORM.

Dzięki strukturom stanowym znaczniki są generowane automatycznie za kulisami, w oparciu o hierarchię aktywnych kontrolek serwera. Kuszące jest, aby te formanty ładowały się i automatycznie utrzymywały swój stan w bazie danych. W tym pomaga ORM.

W pewnym sensie odsuwasz koniec potoku (wyjście HTML) i jest to naturalnie zachęcające do radzenia sobie z początkiem (źródłem danych) w ten sam sposób, dzięki czemu pozostajesz w logice biznesowej tylko w kodzie aplikacji.

Nie to, że nie mówię, że to dobry sposób na robienie różnych rzeczy. Właśnie tam ORM pasuje naturalnie.

2

W aplikacjach, w których masz duży, bardzo połączony model obiektowy, ORM oszczędza ci ciągłego pisania tych samych połączeń.

Inną korzyścią jest leniwe ładowanie, w którym interfejs API ma zwrócić wykres obiektowy, w którym klient interfejsu API użyje tylko podzestawu tego wykresu.

— Paul Sanwald
źródło

1

Uważam, że mylisz ORM z DBAL .

Pojęcie, o którym mówisz, to warstwa abstrakcji bazy danych (DBAL), która pozwala pisać przenośne pliki „sql”, które nie są zależne od bazowego systemu baz danych.

Z drugiej strony ORM (który jest (prawie?) Zawsze zbudowany na DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipedia)

Mówiąc najprościej, ORM pozwala na konwersję danych z płaskiej bazy danych na zawyżoną reprezentację obiektu.

— Craige
źródło

Dziękuję za wyjaśnienie. Głównym powodem, dla którego przeszedłem do ORM, jest skupienie się bardziej na OOP i odejście od pisania tyle SQL, jeśli ma to sens w przypadku niektórych projektów.

— Fred Wilson,

1

Projekty, które nie skorzystałyby z ORM, to:

te, które nie są zorientowane obiektowo;
takie, które nie muszą utrwalać danych;
te, które używają obiektowej DB, a zatem nie potrzebują dodatkowej warstwy mapowania;
te, które używają nierelacyjnego rozwiązania NoSQL;

— vartec
źródło