ORM hâlâ bir anti-pattern mi?

 (github.com/getlago)
7 puan yazan GN⁺ 2023-06-28 | 1 yorum | WhatsApp'ta paylaş
  • ORM, “startup’lar için oyuncak” diye eleştirilse de, asıl mesele çoğu zaman ORM’nin kendisinden çok yanlış kullanım biçimine daha yakındır
  • Nesne grafiği ile ilişkisel tablolar farklı modellerdir; bu yüzden paradigma uyumsuzluğu ortaya çıkar, ancak bu tek başına ORM’yi anti-pattern olarak görmek için yeterli değildir
  • SRP ve SOC ihlali tartışmaları geçerlidir, ancak ORM zaten iki veri modelini birbirine bağlayan bir soyutlama olduğu için yalnızca ilke ihlali üzerinden değerlendirmek zordur
  • Performans sorunları çoğu zaman ORM’den çok veriyi host dil mantığıyla birleştiren desenlerde ortaya çıkar ve ORM’nin SQL benzeri özellikleri ile azaltılabilir
  • Lago’nun Active Record sorgularını ham SQL’e çevirmesindeki temel neden hızdan çok görünürlük ve debug edilebilirlik idi; büyük sorgularda ham SQL’e geçmek pratikte daha avantajlı olabilir

ORM eleştirisine bakışta temel tutum

  • ORM sık sık “anti-pattern” diye hedef alınsa da, ORM’nin kendisinin kötü olduğu sonucu abartılıdır
  • Diğer soyutlamalar gibi ORM de kusursuz değildir ve bir miktar görünürlük kaybı ile performans maliyeti yaratabilir
  • Lago, Ruby on Rails’in ORM’si olan Active Record’a bağımlı olduğu sırada sorunlar yaşadı ve bunu ORM’ye bağımlılık biçimini yeniden gözden geçirmek için bir fırsat olarak kullandı
  • Sonuç, ORM’yi tamamen bırakmak değil; onu artıları ve eksileri net olan bir soyutlama olarak ele almak yönündedir

Nesne modeli ile ilişkisel veritabanı arasındaki fark

  • ORM’nin ele aldığı nesneler, diğer düğümlere işaret eden bir yönlü grafiğe daha yakındır
  • İlişkisel veritabanı tabloları ise paylaşılan anahtarlar üzerinden verinin iki yönlü bağlandığı yönsüz bir grafiğe daha yakındır
  • ORM bu yönsüz grafiği taklit edebilir, ancak yapılandırması ve davranışı her zaman basit değildir
    • User nesnesinde Posts dizisi eksik olabilir
    • Posts dizisindeki varlıklar aynı User nesnesine geri dönen bir referans taşımayabilir
    • Geri dönen bir referans olsa bile aynı nesne yerine onun kopyası olabilir
  • Örneğin ORM, kullanıcının gönderilerini bir dizi olarak döndürürken her gönderide yazar rolündeki kullanıcıya geri referans eklemeyebilir
  • Bu uyumsuzluk ORM’ye yönelik iyi bir akademik eleştiridir, ancak gerçek işletim ortamlarında daha büyük sorunlar somut kullanım biçimlerinde ortaya çıkar

SRP ve SOC tartışması

  • Tek Sorumluluk İlkesi (SRP)

    • ORM’nin Tek Sorumluluk İlkesi (SRP) ’ni ihlal ettiği eleştirisi yapılır
    • Çünkü tek bir sınıf ya da katmanın birden fazla rol üstlenmesine yol açabilir
      • Veritabanı ve transaction yürütme
      • Kayıtların temsili
      • İlişki tanımları
      • Migration oluşturma ve çalıştırma
    • Ancak ORM’nin amacı zaten iki farklı veri paradigmasını birbirine bağlamak olduğu için, yalnızca bazı ilke ihlallerine bakarak ORM’yi reddetmek zordur

  • İlgi alanlarının ayrılması (SOC)

    • ORM, İlgi alanlarının ayrılması (SOC) ilkesini de bulanıklaştırabilir
    • SOC, altyapı bileşenlerinin tek bir ilgi alanına sahip olması gerektiğini söyleyen ilkedir
    • ORM, veritabanı yönetimini backend tarafına taşıdığı için SOC ihlali olarak görülebilir
    • Bununla birlikte günümüzde altyapı bileşenleri ve kodlama kalıpları, performans, gecikme ve kod düzeni için birden fazla rolü birleştirebilmektedir
      • OLAP veritabanı içindeki CPU aggregator
      • Edge backend-frontend
      • Monorepo

Performans sorunu çoğu zaman ORM’den çok kullanım biçiminden kaynaklanır

  • ORM’nin her zaman verimsiz olduğu eleştirisi genellikle yanlıştır
  • Birçok ORM, geliştiricilerin düşündüğünden çok daha verimli çalışabilir
  • Sorun, ORM’nin veriyi JavaScript veya Ruby gibi host dil mantığı ile birleştirmeyi kolaylaştırmasıdır
  • TypeORM örneğinde, önce belirli bir şirkete ait yazarları çekip ardından her yazar için gönderileri yeniden sorgulamak ve her gönderiyi ayrı ayrı kaydetmek kötü bir desen olarak ele alınır
  • Daha iyi yaklaşım, TypeORM’nin createQueryBuilder() özelliğiyle tek bir update sorgusu oluşturmaktır
  • Lago’nun faturalandırma SQL refactor çalışmasında da Active Record ile ham SQL sürümü arasında performans farkı yoktu
    • Active Record’un veri birleştirme özellikleri yoğun biçimde kullanıldığı için mevcut sorgular zaten optimize durumdaydı
    • Ham SQL’e yeniden yazım, performans artışından çok görünürlük kazanmaya hizmet etti

ORM’nin gerçekten yavaşlayabildiği durumlar

  • ORM, her zaman ham SQL kadar verimli değildir; bazı durumlarda kayda değer ölçüde verimsiz olabilir
  • İlk sorun, ORM’nin sorgu sonucunu nesnelere dönüştürürken büyük bir hesaplama overhead’i yaratabilmesidir
    • TypeORM bu probleme örnek olarak anılır
  • İkinci sorun, bire-çok veya çoka-çok ilişkiler dolaşılırken veritabanına birçok gidiş-dönüş isteği gönderilmesidir
  • Bu desen N+1 problemi olarak bilinir
    • Başlangıçtaki 1 sorguya ek olarak N alt sorgu eklenir
    • Prisma örneğinde kullanıcılar, gönderiler ve yorumlar iç içe sorgulanırken her yorum için yeni bir veritabanı isteği oluşabilir
  • N+1, ORM’lerde sık görülür; ancak data loader kullanılırsa N+1 sorgu 2 sorguya indirilebilir
  • ORM’nin yaygın sorunlarının önemli bir kısmı, ORM özellikleri yeterince kullanıldığında önlenebilir

Daha büyük sorun görünürlük ve debug etme

  • ORM’nin en büyük zayıflığı görünürlüktür
  • ORM aslında bir sorgu üreticisi olduğu için, bariz ham tip hataları gibi durumlar dışında son hata ileticisi değildir
  • SQL hatası döndüğünde ORM bunu yorumlayıp kullanıcıya yeniden iletmek zorundadır
  • Active Record bu noktada zorluk yaşadı ve Lago’nun faturalandırma abonelik sorgularını refactor etmesinin nedeni de buydu
  • Beklenenden farklı bir sonuç çıktığında şu süreç tekrar tekrar yaşanıyordu
    • Render edilmiş SQL sorgusunu incelemek
    • O SQL’i yeniden çalıştırmak
    • SQL hatasını Active Record değişikliklerine geri taşımak
  • Bu ileri-geri süreç, SQL veritabanıyla doğrudan etkileşime girmemek için Active Record kullanma amacını zayıflatır

Pratik değerlendirme

  • ORM doğru kullanıldığında ham SQL’e yakın verim sağlayabilir
  • Sorunların çoğu, ORM’nin SQL benzeri özelliklerini kullanmak yerine host dilin mantıksal yapısına aşırı bağımlı olunduğunda ortaya çıkar
  • Büyük sorgular geliştiricileri zorluyor ve debug etmeyi engelliyorsa, ham SQL sorgularına geçmek iyi bir yatırım olabilir
  • Çoğu ORM, ORM içinden SQL sorgusu çalıştırma özelliği sunar

İlgili okumalar

1 yorum

 
GN⁺ 2023-06-28
Hacker News görüşleri

  • Java’da Hibernate ilk çıktığından beri ORM kullanıyorum ama hep kötü buldum
    “Başka bir veritabanına geçebilirsin” avantajı bugünden bakınca neredeyse saçmalık gibi geliyor; pratikte bunu kimse yapmıyor
    “SQL bilmek gerekmiyor” sözü de yanlış; uzun ömürlü, trivial olmayan uygulamalarda eninde sonunda tek tek sorguları string düzeyinde elden ayarlamak gerekiyor
    Veri katmanında doğru yaklaşımın sorguları tek tek string SQL olarak yazıp araya değer yerleştirmek olduğunu düşünüyorum; raw JDBC’ye ne kadar yakınsa o kadar iyi
    ORM’nin “domain model”i desteklediği iddiası da kötü bir gerekçe; çünkü o domain model her zaman mantığı boş olan, anemic domain model haline geliyor
    ORM, XML, annotation’lar ve üretilen SQL’i debug etmeye harcanan zamanı düşününce insanın ağlayası geliyor

    • Kesinlikle katılıyorum. ORM’yi “kolay kısımları biraz daha kolaylaştırıyor ama zor kısımları gerçekten zorlaştırıyor” diye tanımlamak isterim
      Kolay kısımlar zaten kolay, o yüzden pek umurumda değil; asıl sorgular ölçekle çöküşe geçtiğinde ORM’nin kendisiyle boğuşmak yüzünden işin milyon kat zorlaştığı çok oldu
      Query builder ORM ile tamamen aynı şey değil ama https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41... yazısını seviyorum ve Slonik türü teknolojilerin hayranıyım
      Sonuçları nesnelere otomatik bağlama, güçlü tip denetimi gibi istediğim şeylerin %90’ını sağlıyor ama yine de doğrudan normal SQL yazmana izin veriyor
      SQL’in gizemli biçimde zor bir dil olduğu fikrini de anlamıyorum. Eski ve kusurlu olabilir ama ORM araçlarının uydurduğu sorgu dilini öğrenmek yerine SQL öğrenmek daha iyi
    • Ben de ilk kullandığım zamandan beri aynı nedenlerle ORM’den nefret ettim ve bunun bir anti-pattern olduğunu düşündüm
      O zamanlar bu eleştirileri dile getirince diğer geliştiriciler tepeden bakardı
      Bugün de geliştirici olarak mecburen kullanmak zorunda kaldığımız araç ve teknikler arasında anti-pattern çok; sektörün talihsiz gerçeği de yaygın kullanılan araçların önemli bir kısmının kötü olması ve anti-pattern’leri teşvik etmesi
      Teknoloji sektöründe karar gücünü elinde tutan, iyi bağlantılara sahip az sayıda geliştirici ve eski geliştirici var; ve bana kalırsa onlar pek iyi değiller
    • Başlangıcı özellikle mevcut en kötü ORM’lerden biriyle yapmışsın
      Artı-eksi dengesi makul olan ORM’ler de var; özellikle Python tarafında durum iyi
      Django ORM kaba ve performansı çok iyi değil ama entegrasyonu güçlü, pratik, üretken ve kullanımı keyifli
      Peewee, ORM’yi küçük bir paket halinde sunuyor; olağanüstü özelliklere ihtiyaç duymadığında ve uğraşmak istemediğinde küçük programları keyifle yazdırıyor
      SQLAlchemy daha fazla yatırım istiyor ama çok esnek, temiz SQL üretiyor ve doğru çalışıyor
      Nesne yönelimli paradigmayı istemeyip idiomatic SQL davranışını Python ile soyutlayarak ifade etmek isteyenler için daha düşük seviyeli query builder’ları da açığa çıkarıyor
      Sonuçta mesele, her zamanki gibi yatırım getirisi hesabı olan bir mühendislik kararı
    • “String düzeyinde ayar yapmak gerekir” sözü benim deneyimime göre saçmalık
      Bunu 10 yılı aşkın süredir yapıyorum ve Hibernate dokümantasyonunu 5 dakika okuyup o durumda önerilen şeyi yaptığımda çözemediğim tek bir sorgu olmadı
      Sanki bütün geliştiricilerin üç değerli mantık tablolarını ve COBOL tarzı fonksiyon adlarını ezberlemesi gerektiğine inanan SQL fanboy’ları, konu Hibernate dokümanını okumaya gelince bu zahmete girmek istemiyor gibi görünüyor
    • “SQL bilmek gerekmiyor” iddiasını azıcık düşünen hiç kimse ORM’nin avantajı diye sunmadı
      ORM, OLTP workload içindir; OLAP için değil; bunu Hibernate’in kurucularından biri de söylemişti
      Asıl faydası, uzun ve hata üretmeye açık INSERT/UPDATE sorgularını elle yazmak zorunda bırakmaması ve SQL satırlarını nesnelere otomatik eşleştirmesi
      Raw yaklaşıma dönünce bunların önemli bir bölümünü yeniden uygulaman gerekir; dolayısıyla bu da sıfır toplamlı bir oyun değil

  • Yeterince karmaşık uygulamalarda, uygulamanın çeşitli bölümlerinin birlikte sorguları gecikmeli olarak birleştirebildiği bir query builder benzeri şey eninde sonunda ortaya çıkıyor
    Bu, veriyi bellekte birleştirip filtreleyip sıralamak yerine sorgu olarak birleştiren bir yapı oluyor
    ORM bunu kolaylaştıran bir araç ama farkında olmadan N+1 query üretmeyi de kolaylaştırıp insanın ayağına kurşun sıkmasına yol açabiliyor
    Her araçta olduğu gibi gerçek kullanım senaryolarıyla birlikte ödünleşimleri değerlendirmek gerekiyor; SQL cümlesi string'lerini doğrudan manipüle etme yaklaşımını ise hiçbir durumda önermiyorum

    • ORM deneyimi kullanılan dile, entegrasyon seviyesine ve iş türüne göre uç noktalarda değişebilir
      Buna rağmen bu farkları yok sayıp ORM'nin iyi ya da kötü olduğunu mutlak biçimde söyleyen insanlar hep var
      Bunu ilgi çekmek için takınılan tartışmacı bir tavır olarak görüp geçmek daha iyi; ben “ORM'nin faydaları var ama bunların nerede geçerli olduğunu bilmeli ve kullanım sorunlarının faydaları aşmasına izin vermemeliyiz” noktasından başlayan tartışmalara odaklanmak istiyorum
    • Yeterince karmaşık bir uygulamada query builder gerekeceğini doğal bir şey olarak görmüyorum; kendi uygulamamda da bunu kabul etmem
      Veri gerekiyorsa veri erişim katmanına gidilir; o da gerekeni sağlamıyorsa yeni bir repository ya da provider gibi, desene uyan bir şey yapılır
      İster ORM olsun ister elle yapılmış bir sorgu birleştirici, uygulama “yeterince karmaşık olduğu için buna ihtiyacımız var” yanılgısına düşecek hale geldiyse zaten güvenle kullanılmayacak kadar karmaşık hale gelmiştir
      Sonunda builder'ı yanlış katmanda değerlendirmeye ya da sonuçları dolaşırken N+1 query ürettiğinizi kaçırmaya başlarsınız
      ORM gerekli değil
    • Bunun, 2007'de çıkan LINQ'in yaptığı şeye yakın olduğunu düşünüyorum
      LINQ tam olarak bir ORM değil; güçlü biçimde tiplenmiş LINQ ifadeleri yazdığınızda bunlar expression tree'ye dönüşüyor, ardından query provider bunu sorguya çeviriyor
    • Hem ORM hem de raw SQL kullanan biri olarak iki tarafa da hak veriyorum
      Geliştirme sırasında model içinde ORM'nin okunabilirliğini tercih ediyorum ama gerektiğinde N+1 ve diğer verimsizlikleri yakından izleyip optimize ediyorum
      “Gerektiğinde” sınırı net değil ama fazla erken optimizasyon yapmamaya çalışıyorum
      Yeni projelerde genelde veritabanından başlıyorum; kod yazmadan önce factory, seeder ve raw SQL sorgularıyla veri modelinin hissini kavrıyorum
      Laravel'in Eloquent gibi ORM'lerinde N+1'i çözmek ve lazy loading yapmak için iyi yöntemler var ama her zaman ödünleşimler bulunuyor
    • ORM kavramını tersine çeviren kütüphaneler de var
      Gecikmeli sorgu birleştirmeye izin veren bir kütüphane yerine, sorguyu doğrudan yazıyorsunuz ve kütüphane derleme zamanında o sorgu için kod üretiyor
      Örneğin getUser: SELECT * FROM users WHERE id = ? gibi bir sorgu yazınca GetUserQuery sınıfını ve getUser(id: String): GetUserQueryResult gibi bir metodu üretmesi gibi; bence bu model çok daha iyi

  • ORM'den hoşlanmamamın temel nedeni, modern SQL motorlarını abartılı biçimde aptal bir bit deposu gibi ele alma eğilimi
    CTE, LATERAL join ve RETURNING clause işlemleri ciddi ölçüde basitleştirebilir ya da veri tutarsızlığı olasılığını ortadan kaldırabilirken, ORM'ler çoğunlukla temel tabloları ve view'ları önceden tanımlanmış nesnelere basitçe eşlemekle sınırlı kalıyor
    ORM tabloyu da kendisi oluşturuyorsa daha da kötü oluyor
    SQL özünde bir veri çıkarma aracı olmanın yanında bir dönüşüm dili de ama ORM bu yönü neredeyse tamamen görmezden geliyor; böylece pek çok geliştirici SQL'de INSERT/SELECT/UPDATE/DELETE dışında başka neler olduğunu hiç öğrenmiyor
    Pivot table'lar, temporal query'ler, CUBE/ROLLUP, window function'lar, set-returning function'lar, materialized view'lar, external table'lar, JSON işleme, tarih işleme, exclusion constraint'ler, range·interval·domain gibi tipler, row-level security, MERGE ve daha fazlası var
    Sanki elinizde tam donanımlı bir alet atölyesi varken biri size sadece bir çekiç, bir tornavida ve bir demir testeresi verip bunların yeterli olduğuna ikna etmeye çalışıyor; siz de birkaç metre ötede masa testeresi, router, zımpara makinesi ve kama seti olduğundan habersiz tüm kariyerinizi geçiriyorsunuz

    • Çoğu ORM framework'ü raw SQL çalıştırma özelliğine sahip, dolayısıyla ORM kullanmak bu özelliklerden yararlanamayacağınız anlamına gelmiyor
      ORM çoğu zaman insanı basit CRUD ifadeleri üzerinden düşünmeye yönlendiriyor ama bunun muhtemelen daha iyi olduğunu ve gelişmiş özelliklerin idareli kullanılması gerektiğini düşünüyorum
    • Çoğunlukla hiç veritabanı olmayan projelerde çalıştığım için şanslı hissediyorum
      Yine de DB kullanmam gerekirse bilerek DB özelliklerinin çok küçük bir alt kümesini kullanmaya çalışırım
      Çünkü “kod”u kontrol edebildiğim bir alan, “veritabanı”nı ise hataların sonradan yavaş entegrasyon testleri gibi yerlerde ortaya çıktığı, riskli ve dokunması zor bir alan olarak görüyorum
      DB içinde gerçekleşen mantık düşük seviye test kapsamının dışında kaldığı için ürkütücü geliyor; muhtemelen select-from-select sorgusu bile yazmam
      Alet atölyesinin büyük kısmını memnuniyetle kullanmadan bırakırım
    • Bu yüzden birçok geliştiricinin SQL ve NoSQL arasındaki farkı görememesi de şaşırtıcı değil
    • Ölçek büyüdüğünde, performans amacıyla veritabanını yoğun biçimde denormalize edip onu abartılmış aptal bir bit deposu gibi kullanmak yaygınlaşıyor
    • “Böyle gösterişli veritabanı özelliklerine gerek yok” denen birkaç projede bulundum ve ortaya çıkan sonucu yönetmek sinir bozucuydu
      Temel veri bütünlüğü korumalarını yeniden icat etmek için zamanın çoğunu karmaşık dolambaçlı çözümler üretmeye harcadık
      Kendi veritabanını yapmak öğrenmek için eğlenceli olabilir ama production uygulamalar için değil

  • ActiveRecord bana hep iyi hissettirdi
    Bazı istisna durumlar var ama 80/20 noktasını iyi tutturuyor; gerekirse SQL'e kaçış imkânı veriyor ve alan mantığını düzenlemeyi sağlayan lifecycle hook'ları da harika ve anlaşılır
    Her şeyi bir “bundle” arkasına saklamayan ya da kendi sorgu dilini dayatmayan pragmatik ORM'ler iyi
    ORM sorununu tamamen “çözmeye” çalışan ORM'ler ise kullanımı zor olanlar

    • ActiveRecord'u kullanmak gerçekten keyifli; edge case'e rastlayınca da her zaman raw SQL'e dönebiliyorsunuz
      ORM böyle yapılmalı
    • Büyük bir CRUD uygulamasını ActiveRecord olmadan yeniden yapmak zor; okunabilirlik ve bakım yapılabilirlik daha kötü olurdu
      Yalnız bunu doğru kullanmak için SQL hakkında iyi bir ön bilgi şart
      İnsanlar SQL öğrenmeden AR'nin ürettiği sorguları ve sınırlarını anlamadığında sorun çıkıyor
    • ORM hakkındaki şikâyetleri çok anlayamıyorum; bunun nedeni benim kullandığım tek ORM'nin ActiveRecord olması olabilir

  • Varsayım yanlış. ORM hiçbir zaman “zararlı bir fikir” olmadı
    Birlikte çalışması korkunç ORM'ler var, ama bu tüm türün kötü bir fikir olduğu anlamına gelmez
    SQLAlchemy yıllardır keyifle kullanıyorum çünkü SQL kavramının kendisini yeniden icat etmeye çalışmıyor
    Bunun yerine sorguları oluşturup iletmek için kullanışlı bir katman sağlıyor ve küçük ayrıntıları düzgün ele alarak benim elle kurcalamamı gereksiz kılıyor

    • ORM deneyimim neredeyse sadece SQLAlchemy ile sınırlı, Ecto'yu da biraz öğrendim; o yüzden bu başlığı görünce diğer ORM'lerin hepsi gerçekten korkunç mu diye merak ediyorum
      Son zamanlarda Rust öğrenirken basit CRUD işleri için gereken kalıp kodu elle yazmak acı verici ve zaman kaybı gibi geliyor
      SQLAlchemy ORM daha karmaşık ya da optimize edilmeye çalışılan sorgularda biraz engel olabilir, ama böyle durumlarda her zaman doğrudan SQL'e inebilirsin
    • “begging the question” ifadesinin doğru kullanıldığını görmeyeli gerçekten çok olmuştu
    • SQLAlchemy'yi, kodun sorguyla örtüşecek şekilde sana güvenle SQL yazdırması açısından tavsiye edebilirim

  • Her şeyde olduğu gibi, uygun olduğu durumlar ve olmadığı durumlar vardır; teknoloji kolayca aşırı ya da yanlış kullanılabilir
    Örneğin .NET'teki Entity Framework gibi ORM'ler, özellikle database-first yaklaşımla çalışırken büyük bir avantaj olabilir
    Yüzlerce tabloya ve doğru foreign key ilişkilerine sahip bir DB varsa, ORM karmaşık şemada gezinmeye yardımcı olur ve değişikliklerde derleme zamanında kontrol sağlar
    Gömülü SQL performans avantajı gibi görünen iki ucu keskin bir kılıçtır, ama özellikle join'lerde hardcode edilmiş uzun SQL'i bakımda tutmak çok zordur
    Burada 5-10 tabloyu değil, yüzlerce tabloyu kastediyorum
    Kimseyi ikna etmeye çalışmıyorum, ama internette best practice diye okuduğun her şeye olduğu gibi inanmamak gerekir
    İnsanlar tamamen farklı şeylerden söz ediyor olabilir ve hangi teknolojiyi kullanırsan kullan, kötü geliştiriciler her zaman vardır

  • ORM ya da başka bir DB arayüzü kullanmazsan, sonunda CRUD benzeri şeyler için kendin bir tane yazıp bakımını yapmak zorunda kalırsın
    Ve bunun içinde garip bug'lar, edge case'ler ve güvenlik açıkları olma ihtimali yüksektir
    SOLID gibi ilkelerin üniversitede yazılım tasarım ilkeleri olarak öğretilmesinde de sorun var
    Akademide zaman, bakım kolaylığı, para ve emek gibi kısıtlar daha az önemli olduğu için mantıklı görünebilir, ama yeni mezun biri sektöre girince çok kötü bir çarpışma yaşanır
    Çünkü bütün günü “mükemmel” çözümü arayarak oyalanmaya ve tekerleği yeniden icat etmeye alışmış olur
    Bunu frenleyecek yeterli sayıda yetkin senior/lead geliştirici yoksa ortaya çok ilginç bir ürün, bütçe aşımı, büyük yangınlar ya da bunların bir kombinasyonu çıkar
    Daha da kötüsü, akademide üretilip akademi için tasarlanan bir şeyin halka açılmasıdır
    Bunun tipik iyi/kötü örneği OpenStack; CERN ve yüzlerce üniversitenin özel ortamlarını destekleyecek kadar çok düğmesi ve ayar noktası var ve bileşenleri delice modülerleştirilmiş, ama o kadar Bizans usulü ki başlamak neredeyse imkansız

    • Bu başlıkta ORM'nin satıcı vaadiyle örtüşmediğinden şikayet eden çok kişi var ve bu doğru
      ORM veritabanını zahmetsizce değiştirmez, ürettiği SQL'i öğrenip anlama ihtiyacını ortadan kaldırmaz ve şemayı pürüzsüz hale getirmez
      Yine de kullanılmasının nedeni, zaten kopyalamak zorunda kalacağın standart bir soyutlama olmasıdır
      DB erişiminde cache kullanmayı mümkün kılar; bunu elle yazılmış SQL ile yapmak ölçek büyüdükçe şaşırtıcı derecede zorlaşır
      Beraberinde standart araçlar ve best practice'ler gelir; bu da N+1 gibi sorunları önemsiz hale getirebilir
      ORM'nin asıl problemi yanlış beklentiler ve kötü ORM'lerdir
      ORM'nin değerini anlamak istiyorsan, ORM'siz yazılmış bir projeyi aç ve herhangi bir şeyi değiştirmeyi dene
    • “Sonunda kendin bir tane yaparsın” ancak mantığını “satırlar” yerine nesneler etrafında kurmakta ısrar ediyorsan doğrudur
      https://news.ycombinator.com/item?id=36498583 bağlantısına bak
    • Bazı ekipler ve çeşitli şirketler, bir ya da birkaç süper dahinin mükemmelliğin peşine düşmesi yüzünden zorlandı ya da başarısız oldu
      Faydalı işler ilerlemedi ya da hızlı ve dağınık bir yaklaşıma göre 20-100 kat daha uzun sürdü
      En kötüsü, yetkin bir HTML tasarımcı ekibinin fonksiyonel programlama öğrenmeye zorlandığı durumdu
      Backend yapılandırma sihirbazı modern mühendisliğin ve zarif tasarımın bir harikasıydı, ama 10 kişinin 1 yılını aldı
      VC parası insanları tuhaflaştırıyor
    • SQLAlchemy hakkında o kadar çok olumsuz şey duydum ki kendim hafif bir query builder yapmaya karar verdim, ama 8 ay sonra dönüp dolaşıp yine SQLAlchemy kullanıyordum
      SQL dili çok karmaşık ve gerçekten düzgün, tam özellikli bir query builder yapmak hiç de önemsiz değil
      Asıl ilişkisel eşleme kısmını bir kenara bıraksan bile durum böyle
    • İyi bir ORM kullanmak daha iyidir; aksi halde kötü bir ORM'nin yarısını kendin üstlenmiş olursun

  • SQL için durumun gerçekten de “lanet olası şeyi doğrudan kendin programla” olduğunu düşünüyorum
    SQL ya da ORM kütüphanelerini öğrenmenin pek anlamı yok; SQL'i doğrudan öğrenip kullanmak daha iyi
    Veritabanı erişimi muhtemelen kariyerin boyunca yapacağın temel işlerden biri olacak, bu yüzden gerçek tekniği doğrudan öğrenmek en iyisi
    CSS de benzer; CSS kütüphanelerini öğrenmek yerine CSS'i öğrenip kullanmak gerekir
    Aslında frontend geliştirmenin neredeyse her alanı için de bu geçerli; “form kütüphanesi” yerine tarayıcının form API'sini doğrudan kullanabilirsin
    Bana göre SQL, herhangi bir ORM'den çok daha kolay öğrenildi
    Yanlış şeyi öğrenmenin maliyetini boşa harcamamak gerekir

    • Önce SQL öğrenirsen, ne zaman ORM kullanman gerektiğini de anlarsın ve ORM'leri daha iyi değerlendirebilirsin
      CSS için de aynı şey geçerli; CSS biliyorsan, kolaylık için bir kütüphane seçerken çok daha esnek olur ve onu daha iyi anlarsın
    • SQL'e sonsuz dil deniyordu
      Mainframe, masaüstü, istemci/sunucu, web gibi pek çok geliştirme platformundan ve bunların üzerindeki çeşitli dillerden geçerken SQL her zaman ortak bağ oldu
      Veri katmanını ve onun altında neler olup bittiğini iyi bilen geliştiricilerin daha güçlü geliştiriciler olduğuna tamamen katılıyorum
      Eğer bir ORM'nin tuhaflıklarını öğrenmeye zaman harcayacaksan, neden o zamanı SQL öğrenmeye yatırmıyorsun sorusu klasik bir sorudur
      SQL deneyiminin bileşik getirisi, 10-15 yıl sonra belirli bir platform ya da dilin ORM'sinden daha değerli olabilir
      ORM öğrenmek ve kullanmak için nedenler var, ama sırf SQL öğrenmek istemediğin için ORM tarafına kaymamalısın
    • Mesele daha çok “soyutlamayı öğrenmeden önce önce temeli öğren” meselesi
      Ancak o zaman bu soyutlama için ne bedel ödediğini bilirsin. Tabii “sıfır maliyetli soyutlama” ise başka
    • 1992'den beri Pro*Pascal, CS130 ile SQL'i doğrudan yazıyorum
      Ama şimdi Go tipleriyle marshalling/unmarshalling yüzünden ORM sayılabilecek azer crud kullanıyorum
      Go standart kütüphanesindeki sql fazla temel; nesne marshalling/unmarshalling işini fiilen kendin yazman gerekiyor ve bu gerçekten sıkıcı
      Bugünlerde ORM kullanacak olsam, muhtemelen sadece bu amaçla kullanırdım

  • Dapper veya Diesel gibi “orta nokta” mikro ORM'leri seviyorum
    Sorguları SQL ile yazıyorsun ama güçlü tipler ve sonuç kümesinin nesnelere otomatik eşlenmesini elde ediyorsun
    Böylece hem üretkenliği hem de tam özellikli “gerçek” bir sorgu dilini birlikte alıyorsun
    Ayrıca nesne eşleyicileri yalnızca salt-okunur sorgular için kullanma yaklaşımını da sevmeye başladım
    Güncellemeler komut deseniyle, yani stored procedure'lerle yapılır ve bunlar native metotlarmış gibi eşlenebilir

    • Dapper, şimdiye kadar kullandığım veri erişim çözümleri arasında en keyiflisi oldu
      Geliştiriciler SQL yokmuş gibi davranmayı bırakıp bunu kabullenmeli
    • Model fonksiyonlarını sonuçta yalnızca SQL'e eşlenecek şekilde elle yazmak ya da parametreli sorguları doğru çalıştırmak için kalıp PHP kodu yazmak zorunda olmamak hoşuma gidiyor
      Eloquent, bu angaryayı yeterince soyutlayarak mantığa odaklanmayı sağlıyor
      Sadece diziler ve sorgulardan oluşan “eski” bir PHP uygulamasını modeller ve Eloquent kullanan bir yapıya yeniden yazıyorum; bu tam anlamıyla oyunun kurallarını değiştiriyor gibi hissettiriyor
    • Orta nokta iyi. TypeScript tarafında örneğin Kysely ya da kendi projem Zapatos var
    • Bence en iyi nokta bu
      Eskiden .NET üzerinde SQLite kullanırken ben de bu yönde bir wrapper kütüphanesi yazmıştım: https://github.com/zmj/sqlite-fast

  • Bu başlık, ORM'nin zihin payı üzerindeki hâkimiyetini iyi gösteriyor
    Neredeyse bütün yorumlarda ORM'nin örtük alternatifi, uygulama kodunun içinde string literal olarak yazılmış raw SQL
    Oysa daha 6 yıl önce SQL'i başlı başına bir dil olarak kullanıp sorguları uygulamada metot olarak sunan wrapper'lar üreten araçlar vardı
    queryfirst, pgtyped, pugsql, sqlc gibi
    Bu bir paradigma değişimiydi ya da en azından öyle olabilirdi ve açıkça daha üstün bir çalışma biçimi olduğu görülüyor, ama ORM ve hiç değişmeyen bu tartışma tüm oksijeni tüketip bunu kenarda bırakıyor

    • Evet. Go tarafında sqlc de var
      SQL bir dildir, hem de oldukça yüksek seviyeli bir dil
      SQL'i daha düşük seviyeli bir dille birleştirmeye çalışmak, “elinde çekiç varsa her şey çivi gibi görünür” durumunun tipik örneği
      Örneğin düşük seviyeli assembly ile kod yazıp büyük bir sistemle etkileşime giriyorsun ve bu sistemin dokümantasyonu girdinin yalnızca JavaScript ile ifade edilebildiğini söylüyor olsun; önünde seçenekler var
      Her şeyi saf assembly ile bir araya getirmene yarayan karmaşık bir kütüphane alıp depoya xxx.js dosyası commit etmeyebilirsin ya da doğrudan .js dosyasıyla yüksek seviyeli dilin gücünü kullanarak bunu ifade edebilirsin
    • sqlc'yi bir projede kullandıktan sonra geri dönmek istemeyeceğimi düşünüyorum
      Kullanılan SQL sorguları için tek bir doğruluk kaynağı oluşuyor ve gerçekten yazıp bakımını yaptığın şey sorguların kendisi olduğu için yeni indeksler oluşturmak gibi optimizasyonlar da kolaylaşıyor
    • ActiveRecord bana hep zayıf geldi ama içinde sorgu oluşturan arel hep hoşuma gitti
      Raw SQL string'leri üzerine soyutlama koymak çok faydalı, ama ilişkileri nesneymiş gibi göstermek karmaşık ve dolaşık bir yaklaşım
    • NeXT'in Enterprise Objects Framework'ü bunu 25 yıldan daha uzun süre önce zaten destekliyordu
      TopLink de muhtemelen öyleydi
      Stored procedure'ler ile yerel entity'ler arasındaki eşlemeyi ele alış biçimi buydu
    • Hangi araçlar olduklarını merak ediyorum