ORM neden en iyi tercihiniz olmamalı

Birkaç yıl önce programlamaya başladığımda ORM, yazılım projelerinin can damarı gibiydi. Çevre, kod tabanı ile ORM katmanı arasındaki sıkı bağlantıyı vurguladı. ORM'siz projeleri düşünmemem için eğitilmiş olduğum söylenebilir.

Ancak belirli projeler hakkında deneyim ve daha fazla bilgi edindiğimde, iyileştirmelerin çoğunun nihayetinde akışın ORM çerçevesine girdiği noktaya geldiğini fark ettim. Kendime şu soruyu sordum: ya bu projede ORM yoksa?

ORM'nin karşılaştığı sorunları düşünmeye başladım:

  • Bu ekstra hız patlamasına gerçekten ihtiyacınız olsa bile kodunuzu optimize edemezsiniz; ORM kodu kendi ülkesinde yaşıyor.
  • Neler olduğuna dair görünürlük asgari düzeydedir.
  • Belgeler genellikle büyük ve parçalara ayrılmıştır ve bu da özelliklerin aranmasını zorlaştırır.

Bunlar küçük sorunlar gibi görünebilir ancak üretkenliği ciddi şekilde incitir. Bunların dışında ORM ekosisteminin ana web geliştirmeden kendi markaları ve sınırlamaları ile ayrıldığını fark ettim. ORM'ler genellikle gereksiz karmaşıklık getirir ve veritabanı etkileşimleri üzerinde “sızdıran soyutlama” sağlar. Bazen dik bir öğrenme eğrisi vardır ve geliştiriciler kara kutu gibi davranma eğilimindedir.

Geliştiricilerin ORM sorununu çözmek için çeşitli yaklaşımlar izlediklerini gördüm. Bazıları, projenin karmaşıklığına bağlı olarak genellikle Herkül'ün görevi olan ORM çerçevelerini tamamen kaldırmaktadır. Bazıları ORM'yi kabul eder ve projelerinde kod uyarlar; performanstan ödün vermeye hazırlar ve ilave karmaşıklığı önemsemiyorlar. Birçoğu ORM'yi kullanmaya devam ettikleri altın yolu seçer, ancak yeni veya karmaşık sorgular hariç tutulur. Bazıları aslında projeye özgü ve ihtiyaca göre kendi harita katmanlarını yaratıyor.

Şimdiye kadar, Hibernate (Java) ve Mongoose (MongoDB için Düğümdeki ORM çerçevesi) ile çalıştım. Mongoose’u ORM olarak kullanan bir Node projesine geldiğimde, neredeyse tüm projeyi yeniden yapılandırma anıtsal görevim vardı. İlk başta ORM çerçevesini tamamen kaldırmayı düşündüm. Ancak meslektaşlarım beni desteklemeden numaralar olmadan tatmin olmazlardı. Bu yüzden sorgu süresini Mongoose ile ve Mongoose olmadan karşılaştırdım. Sonuçlar burada.

Beni şaşırttı. Mongoose'u kullanmadığım zamanlarda performans kazancı beklemekteydim, ancak bu kadar değil. Bu veriler el altındayken seçim açıktı: ORM dışarıdaydı. Birkaç ay sonra, bir meslektaşım bir Postgres veritabanına erişmek için Sequelize veya Pg kullanmaları gerektiğini söyledi. Sequelize’in bir ORM olduğunu fark ederek, oyumu Pg’ye verdim, ancak ikisini kıyaslamasını istedim. ORM nefretinin haklı olup olmadığını doğrulamak istedim ve sayılar geri geldiğinde, bunun gerçekten haklı çıktığını ortaya koydu.

Tahmin et hangi kütüphaneyle devam etti.

Burada hatırlanması gereken bir şey, ORM'lerden vazgeçtiğimiz, Mongoose veya Sequelize olunca, neyin pes etmekte olduğunun farkındaydık. Özellikle şema kontrolü, önceden oluşturulmuş yöntemler, soyutlamalar vs. bir ORM çerçevesi kullanmanın getirdiği tehlikelerdi. En büyük endişe, şema denetiminin olmaması (ORM kullanılmadığında), veri tabanına veri girmesine neden olabilecek bir şeydi. Bunun üstesinden gelmek için performansı bozulmadan tutarken görevimizi kolaylaştıran Joi'yi kullandık. Diğer bölümler için birkaç satır ekstra kod yazmamız gerekiyordu ancak buna değdi. Her sorguda onlarca milisaniyeyi (bazen bile birkaç saniye) kaybetmemek daha iyidir.

ORM'leri basmaya çalışmıyorum ve yeni başlayanlar ve küçük ölçekli projeler için gerçekten çok iyi. Ancak, projeniz çok sayıda sorgu ve belgeye ölçeklendiğinde, ORM'ler bir darboğaz olabilir. Bunları Vietnam savaşı olarak düşünün, ne zaman çekilip kaçılacağına karar vermeniz gerekir, aksi takdirde büyük hasar kaçınılmazdır.