Jakie projekty programistyczne korzystają z ORM?

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?

(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ź.

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).

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.

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.

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.

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;