ORM kullanmamak için iyi nedenler var mı? [kapalı]

Çıraklığım sırasında, çoğunlukla kendi başıma kodlayıp tasarladığım bazı küçük projeler için NHibernate kullandım . Şimdi, daha büyük bir projeye başlamadan önce, veri erişiminin nasıl tasarlanacağı ve bir ORM katmanının kullanılıp kullanılmayacağı tartışıldı. Hâlâ çıraklık dönemimde olduğum ve kendimi kurumsal programlamada yeni başlayan biri olarak gördüğüm için, bence gerçekten zorlamaya çalışmadım, bu da veritabanına bir nesne ilişkisel eşleştiricisi kullanmak gelişimi oldukça kolaylaştırabilir. Geliştirme ekibindeki diğer kodlayıcılar benden çok daha deneyimli, bu yüzden sadece dediklerini yapacağımı düşünüyorum. :-)

Bununla birlikte, NHibernate veya benzer bir projeyi kullanmamanın ana nedenlerinden ikisini tam olarak anlamıyorum:

1. Kişi yalnızca SQL sorguları ile kendi veri erişim nesnelerini oluşturabilir ve bu sorguları Microsoft SQL Server Management Studio dışına kopyalayabilir.
2. Bir ORM'de hata ayıklamak zor olabilir.

Yani, elbette veri erişim katmanımı çok sayıda SELECTs vb. İle oluşturabilirim, ancak burada otomatik birleştirmelerin, tembel yükleme proxy sınıflarının ve bir tablo yeni bir sütun alırsa veya bir sütun alırsa daha az bakım çabasının avantajını özlüyorum yeniden adlandırıldı. (Sayısız güncellenmesi SELECT, INSERTve UPDATEharitalama yapılandırma güncellenmesi ve muhtemelen iş sınıfları ve DTOs üstlenmeden vs sorgular.)

Ayrıca, çerçeveyi çok iyi bilmiyorsanız, NHibernate'i kullanarak öngörülemeyen sorunlarla karşılaşabilirsiniz. Bu, örneğin, otomatik olarak doğrulanacak bir dizenin uzunluğunu ayarladığınız Table.hbm.xml dosyasına güvenmek olabilir. Ancak, "basit" bir SqlConnection sorgu tabanlı veri erişim katmanında da benzer hataları hayal edebiliyorum.

Son olarak, yukarıda bahsedilen argümanlar, önemsiz olmayan bir veritabanı tabanlı kurumsal uygulama için bir ORM kullanmamak için gerçekten iyi bir neden mi? Muhtemelen kaçırmış olabileceğim başka argümanlar var mı?

(Muhtemelen bunun, ekip çalışması gerektiren ilk "büyük" .NET / C # tabanlı uygulama gibi olduğunu düşündüğümü eklemeliyim. Stack Overflow'da oldukça normal görülen birim testi veya sürekli entegrasyon gibi iyi uygulamalar, -şimdiye kadar burada mevcuttur.)

Son yıllarda ORM'lerde bir büyüme patlaması yaşandı ve daha deneyimli iş arkadaşlarınız hala "her veritabanı çağrısı bir saklı yordam aracılığıyla yapılmalıdır" mantığıyla düşünüyor olabilir.

Bir ORM neden hata ayıklamayı zorlaştırır? Depolanan bir işlemden veya ORM'den gelse de aynı sonucu alırsınız.

Sanırım bir ORM ile aklıma gelen tek gerçek zarar, güvenlik modelinin biraz daha az esnek olmasıdır.

DÜZENLEME: Sorunuzu yeniden okudum ve sorguları kopyalayıp satır içi sql'ye yapıştırıyorlar. Bu, güvenlik modelini bir ORM ile aynı kılar, bu nedenle bu yaklaşıma göre bir ORM'ye göre kesinlikle hiçbir avantaj olmayacaktır. Parametrelenmemiş sorgular kullanıyorlarsa, bu aslında bir güvenlik riski olacaktır.

Kısa cevap evet, gerçekten iyi nedenler var. Aslında, bir ORM kullanamayacağınız durumlar vardır.

Örnek olarak, büyük bir kurumsal finans kurumu için çalışıyorum ve birçok güvenlik kuralına uymamız gerekiyor. Tarafımıza konulan kural ve düzenlemelere uymak için denetimleri geçmenin tek yolu, veri erişimini saklı prosedürler dahilinde tutmaktır. Şimdi bazıları bunun aptalca olduğunu söyleyebilir, ama dürüst olmak gerekirse öyle değil. Bir ORM aracı kullanmak, aracın / geliştiricinin istediği şeyi ekleyebileceği, seçebileceği, güncelleyebileceği veya silebileceği anlamına gelir. Depolanan prosedürler, özellikle müşteri verileriyle uğraşırken ortamlarda çok daha fazla güvenlik sağlar. Bence bu, dikkate alınması gereken en büyük neden. Güvenlik.

ORM'lerin tatlı noktası

ORM'ler, uygun oldukları yerlerde sorguların% 95'ten fazlasını otomatikleştirmek için kullanışlıdır. Onların özel gücü, güçlü bir nesne modeli mimarisine sahip bir uygulamanız ve bu nesne modeliyle güzelce çalışan bir veritabanına sahip olmanızdır. Yeni bir yapı yapıyorsanız ve ekibinizde güçlü modelleme becerilerine sahipseniz, muhtemelen bir ORM ile iyi sonuçlar alacaksınız.

El ile yapılması daha iyi olan bir avuç sorgunuz olabilir. Bu durumda, bunun üstesinden gelmek için birkaç saklı yordam yazmaktan korkmayın. Uygulamanızı birden çok DBMS platformuna taşımayı planlasanız bile, veritabanına bağlı kod azınlıkta olacaktır. Uygulamanızı desteklemeyi düşündüğünüz herhangi bir platformda test etmeniz gerekeceğini akılda tutarak, bazı depolanmış prosedürler için fazladan taşıma çabası, toplam sahip olma maliyetinizde çok fazla fark yaratmayacaktır. İlk yaklaşım olarak,% 98 taşınabilirlik,% 100 taşınabilirlik kadar iyidir ve bir ORM'nin sınırları etrafında çalışmak için kıvrımlı veya düşük performanslı çözümlerden çok daha iyidir.

Eski yaklaşımın çok büyük (100 personel yılı) bir J2EE projesinde işe yaradığını gördüm.

ORM'nin en uygun olmayabileceği durumlarda

Diğer durumlarda, uygulamaya ORM'den daha iyi uyan yaklaşımlar olabilir. Fowler'ın Kurumsal Uygulama Mimarisi Modelleri, buna çeşitli yaklaşımları kataloglamak için oldukça iyi bir iş çıkaran veri erişim modelleriyle ilgili bir bölüme sahiptir. Bir ORM'nin uygulanamayabileceği durumlara ilişkin gördüğüm bazı örnekler şunlardır:

• Depolanan yordamların önemli bir eski kod tabanına sahip bir uygulamada, görevdeki zincirleri sarmak için işlevsel olarak yönlendirilmiş (işlevsel dillerle karıştırılmamalıdır) bir veri erişim katmanı kullanmak isteyebilirsiniz. Bu, genellikle oldukça önemli bir geliştirme ve test çabasını temsil eden mevcut (ve dolayısıyla test edilen ve hataları ayıklanan) veri erişim katmanını ve veritabanı tasarımını yeniden kullanır ve verileri yeni bir veritabanı modeline geçirmek zorunda kalmadan tasarruf sağlar. Java katmanlarını eski PL / SQL kod tabanlarının etrafına sarmak veya web arayüzleriyle zengin istemci VB, Powerbuilder veya Delphi uygulamalarını yeniden hedeflemek genellikle oldukça iyi bir yoldur.

• Bir varyasyon, VEYA eşlemesine mutlaka uygun olmayan bir veri modelini devraldığınız yerdir. Eğer (örneğin) yabancı bir arayüzden verileri dolduran veya çıkaran bir arayüz yazıyorsanız, veritabanıyla doğrudan çalışmak daha iyi olabilir.

• Finansal uygulamalar veya sistemler arası veri bütünlüğünün önemli olduğu diğer sistem türleri, özellikle de iki aşamalı kesinleştirme ile karmaşık dağıtılmış işlemler kullanıyorsanız. İşlemlerinizi bir ORM'nin destekleyebileceğinden daha iyi bir şekilde yönetmeniz gerekebilir.

• Veritabanı erişiminizi gerçekten ayarlamak istediğiniz yüksek performanslı uygulamalar. Bu durumda daha düşük seviyede çalışmak tercih edilebilir.

• ADO.Net gibi 'yeterince iyi' bir yerleşik veri erişim mekanizması kullandığınız ve platformla güzelce oynadığınız durumlar, ORM'nin getirdiklerinden daha büyük fayda sağlar.

• Bazen veriler yalnızca veridir - örneğin, uygulamanızın "nesneler" yerine "işlemler" ile çalıştığı ve bu alanın mantıklı bir görünümü olduğu durumlar olabilir. Buna bir örnek, yapılandırılabilir analiz alanlarına sahip işlemlerinizin olduğu bir finans paketi olabilir. Uygulamanın kendisi bir OO platformu üzerine kurulabilirken, tek bir iş etki alanı modeline bağlı değildir ve GL kodları, hesaplar, belge türleri ve yarım düzine analiz alanından çok daha fazlasının farkında olmayabilir. Bu durumda, uygulama bir iş etki alanı modelinin farkında değildir ve bir nesne modeli (genel muhasebe yapısının ötesinde) uygulamayla ilgili değildir.

İlk olarak - bir ORM kullanmak, kodunuzun test edilmesini kolaylaştırmayacak ve bir Sürekli Entegrasyon senaryosunda mutlaka herhangi bir avantaj sağlamayacaktır.

Deneyimlerime göre, bir ORM kullanmak geliştirme hızını artırabilirken, ele almanız gereken en büyük sorunlar şunlardır:

1. Kodunuzu test etme
2. Kodunuzu korumak

Bunların çözümleri:

1. Kodunuzu test edilebilir hale getirin ( SOLID ilkelerini kullanarak )
2. Mümkün olduğunca çok kod için otomatik testler yazın
3. Otomatik testleri olabildiğince sık çalıştırın

Sorunuza gelince, listelediğiniz iki itiraz her şeyden çok cehalet gibi görünüyor.

SELECT sorgularını elle yazamamak (ki bu yüzden kopyala-yapıştır işleminin gerekli olduğunu düşünüyorum) bazı SQL eğitimlerine acil bir ihtiyaç olduğunu gösteriyor gibi görünüyor.

ORM kullanmamamın iki nedeni var:

1. Şirketin politikası tarafından kesinlikle yasaktır (bu durumda başka bir yerde çalışmaya giderim)
2. Proje son derece veri yoğun ve satıcıya özel çözümler (BulkInsert gibi) kullanmak daha mantıklı.

ORM'ler (özellikle NHibernate) ile ilgili olağan redler şunlardır:

1. Hız

   ORM kullanmanın elle kodlanmış Veri Erişiminden daha yavaş olmasının hiçbir nedeni yoktur. Aslında, yerleşik önbelleğe alma ve optimizasyonlar nedeniyle daha hızlı olabilir. İyi bir ORM, şemanızı optimize edebileceğiniz tekrarlanabilir bir sorgu seti üretecektir. İyi bir ORM, çeşitli getirme stratejileri kullanarak ilişkili verilerin verimli bir şekilde alınmasına da izin verecektir.

2. Karmaşıklık

   Karmaşıklıkla ilgili olarak, bir ORM kullanmak daha az kod anlamına gelir, bu da genellikle daha az karmaşıklık anlamına gelir. Elle yazılmış (veya üretilen kod) veri erişimini kullanan birçok kişi, "düşük düzeyli" veri erişim kitaplıkları (ADO.Net için yardımcı yöntemler yazmak gibi) üzerine kendi çerçevelerini yazarken bulurlar. Bunlar daha fazla karmaşıklığa eşittir ve daha da kötüsü, nadiren iyi belgelenirler veya iyi test edilirler.
   Özellikle NHibernate'e bakıyorsanız, Fluent NHibernate ve Linq To NHibernate gibi araçlar da öğrenme eğrisini yumuşatır.

Tüm ORM tartışması hakkında beni çeken şey, bir ORM kullanmanın çok zor / yavaş olacağını iddia eden aynı kişiler / Linq To Sql veya Typed Datasets kullanmaktan fazlasıyla mutlu olan aynı kişilerdir. Linq To Sql doğru yönde atılmış büyük bir adım olsa da, bazı açık kaynaklı ORM'lerin olduğu yerlerde hala ışık yılı geride kalıyor. Bununla birlikte, hem Typed Datasets hem de Linq To Sql için çerçeveler hala oldukça karmaşıktır ve bunları (Tablo = Sınıf) + (temel CRUD) 'nin çok uzağına gitmek için kullanmak aptalca zordur.

Tavsiyem, günün sonunda bir ORM alamazsanız, veri erişiminizin kodun geri kalanından ayrı olduğundan ve Gang Of Four'un kodlama tavsiyesine uyduğunuzdan emin olun. bir arayüz. Ayrıca, kablolamayı yapmak için bir Bağımlılık Enjeksiyon çerçevesi edinin.

(Bu nasıl bir rant için?)

Hibernate gibi ORM araçlarının tanrı tarafından gönderildiği çok çeşitli ortak sorunlar vardır ve bunların birkaçı engel teşkil eder. Hangisi olduğunu bilecek kadar projeniz hakkında yeterince bilgim yok.

Hibernate'in güçlü noktalarından biri, bir şeyleri yalnızca 3 kez söyleyebilmenizdir: sınıfta, .hbm.xml dosyasında ve veritabanında her özellikten bahsedilir. SQL sorguları ile özellikleriniz sınıfta, veritabanında, select deyimlerinde, insert deyimlerinde, güncelleme deyimlerinde, delete deyimlerinde ve SQL sorgularınızı destekleyen tüm sıralama ve unmarshalling kodlarında bulunur! Bu, hızla dağınık hale gelebilir. Öte yandan, nasıl çalıştığını biliyorsun. Hata ayıklayabilirsiniz. Hepsi orada kendi kalıcılık katmanınızda, 3. taraf bir aracın bağırsaklarına gömülü değil.

Hibernate, Spolsky'nin Sızdıran Soyutlamalar Yasası'nın bir poster çocuğu olabilir. Alışılmış yoldan biraz uzaklaşın ve aletin derinlemesine iç işleyişini bilmeniz gerekir. Dakikalar içinde SQL'i düzeltebileceğinizi bildiğinizde çok can sıkıcı olabilir, ancak bunun yerine dang aracınızı makul SQL oluşturmak için kandırmaya çalışmakla saatler harcıyorsunuz. Hata ayıklama bazen bir kabustur, ancak orada bulunmayan insanları ikna etmek zordur.

DÜZENLEME: NHibernate hakkında geri çevrilmeyeceklerse ve SQL sorguları üzerinde kontrol sahibi olmak istiyorlarsa iBatis.NET'e bakmak isteyebilirsiniz.

DÜZENLEME 2: Yine de büyük kırmızı bayrak: "Stack Overflow'da oldukça normal görülen, birim testi veya sürekli entegrasyon gibi iyi uygulamalar şimdiye kadar burada yok." Peki, bu "deneyimli" geliştiriciler, geliştirme konusunda ne deneyimliler? İş güvenliği mi? Alanla özellikle ilgilenmeyen insanlar arasında görünüyorsunuz, bu yüzden ilginizi kesmelerine izin vermeyin. Denge olmalısın. Bir kavga çıkar.

ORM kullanmamanın çok başarılı olduğu bir proje üzerinde çalıştım. Bir projeydi

1. Başlangıçtan itibaren yatay ölçeklenebilir olmalı
2. Hızlı bir şekilde geliştirilmesi gerekiyordu
3. Nispeten basit bir alan modeline sahipti

NHibernate'in yatay olarak bölümlenmiş bir yapıda çalışması için gereken süre, bölümleme şemamızın farkında olan süper basit bir veri belirleyici geliştirmek için geçen süreden çok daha uzun olurdu ...

Yani, bir ORM üzerinde çalıştığım projelerin% 90'ında paha biçilmez bir yardımcı oldu. Ama bir ORM kullanmamayı en iyi olarak görebildiğim çok özel durumlar var.

Öncelikle, ORM'lerin doğru bir şekilde entegre edilirse geliştirme hayatınızı kolaylaştırabileceğini söylememe izin verin, ancak ORM'nin belirttiğiniz gereksinimlere ve hedeflere ulaşmanızı gerçekten engelleyebileceği bir avuç problem var.

Yüksek performans gereksinimleri olan sistemleri tasarlarken, çoğu zaman sistemi daha performanslı hale getirmenin yollarını bulmakta zorlandığımı fark ettim. Çoğu zaman, ağır bir yazma performansı profiline sahip bir çözüm buluyorum (yani verileri okuduğumuzdan çok daha fazla veri yazıyoruz). Bu durumlarda, performans hedeflerimize (OLAP değil, OLTP) ulaşmak için veritabanı platformunun bana sunduğu olanaklardan yararlanmak istiyorum. Öyleyse, SQL Server kullanıyorsam ve yazacak çok verim olduğunu biliyorsam, neden toplu ekleme kullanmayayım ... daha önce keşfetmiş olabileceğiniz gibi, çoğu ORMS (bilmiyorum) tek biri bile) toplu ekleme gibi platforma özgü avantajlardan yararlanma yeteneğine sahip değildir.

ORM ve ORM dışı teknikleri harmanlayabileceğinizi bilmelisiniz. ORM'lerin gereksinimlerinizi destekleyemediği ve bu durumlar için bunların etrafında çalışmanız gereken bir avuç uç durum olduğunu buldum.

50000000 kaydı güncellemeniz gerektiğinde. Bir bayrak falan koyun.

Bir ORM kullanarak bu yöntemi deneyin olmadan saklı yordam veya yerli SQL komutlarını çağıran ..

Güncelleme 1: Yalnızca birkaç alanı olan bir kaydı almayı da deneyin. (Çok "geniş" bir masanız olduğunda). Veya skaler bir sonuç. ORM'ler bu konuda da berbat.

GÜNCELLEME 2 : Görünüşe göre EF 5.0 beta toplu güncellemeler vaat ediyor ancak bu çok sıcak bir haber (2012, Ocak)

Önemsiz olmayan bir veritabanı tabanlı kurumsal uygulama için, ORM kullanmamanın hiçbir gerekçesi yoktur.

Özellikler bir yana:

• Bir ORM kullanmayarak, büyük topluluklar veya önemli kaynaklara sahip şirketler tarafından defalarca çözülmüş bir sorunu çözüyorsunuz.
• Bir ORM kullanarak, veri erişim katmanınızın temel parçası o topluluğun veya şirketin hata ayıklama çabalarından yararlanır.

Argümana biraz perspektif katmak için, ADO.NET kullanmanın, tablo şeklindeki veri akışını kendi başına ayrıştırmak için kodu yazmanın avantajlarını göz önünde bulundurun.

Bir ORM'yi bir geliştiricinin ORM'leri küçümsemesini haklı çıkarmak için nasıl kullanılacağına dair cehalet gördüm Örneğin: istekli yükleme (bahsetmediğini fark ettiğim bir şey). Bir müşteriyi ve tüm siparişlerini ve bunlar için tüm sipariş detay öğelerini almak istediğinizi hayal edin. Yalnızca geç yüklemeye güveniyorsanız, ORM deneyiminizden şu görüşle uzaklaşacaksınız: "ORM'ler yavaş." İstekli yüklemeyi nasıl kullanacağınızı öğrenirseniz, 5 satır kodla 2 dakika içinde yapacaksınız, iş arkadaşlarınızın uygulaması yarım gün alacak: veritabanına bir sorgu ve sonuçları bir nesneler hiyerarşisine bağlama. Başka bir örnek, sayfalamayı uygulamak için SQL sorgularını manuel olarak yazmanın acısı olabilir.

ORM kullanmanın olası istisnası, bu uygulamanın, özel iş mantığı soyutlamalarını uygulamak için tasarlanmış ve birden fazla projede yeniden kullanılmak üzere tasarlanmış bir ORM çerçevesi olması olabilir. Durum böyle olsa bile, mevcut bir ORM'yi bu soyutlamalarla geliştirerek daha hızlı benimsenirsiniz.

Üst düzey ekip üyelerinizin deneyimlerinin sizi bilgisayar biliminin evriminin tersine sürüklemesine izin vermeyin. 23 yıldır profesyonel olarak geliştiriyorum ve sabitlerden biri de eski ekolün yeniyi küçümsemesidir. ORM'ler, C dili derleme için olduğu gibi SQL içindir ve C ++ ve C # eşdeğerlerinin yolda olduğuna bahse girebilirsiniz. Yeni okul kodunun bir satırı, 20 satırlık eski ekole eşittir.

Belki daha büyük sistemler üzerinde çalışırken, ORM yerine CodeSmith gibi bir kod üretme aracı kullanabilirsiniz diye düşünüyorum ... Kısa süre önce şunu buldum: SQL Server Depolanan Prosedürleri oluşturan ve aynı zamanda iş varlıklarınızı, haritacılarınızı, ağ geçitlerinizi oluşturan Cooperator Framework , tembel yük ve C #'daki tüm o şeyler ... kontrol edin ... buradaki bir ekip tarafından Arjantin'de yazılmıştır ...

Sanırım, tüm veri erişim katmanını kodlamak ve bir ORM kullanmak arasında ortada ...

Kişisel olarak, (yakın zamana kadar) bir ORM kullanmaya karşı çıktım ve tüm SQL komutlarını kapsayan bir veri erişim katmanı yazarak idare etmeye alıştım. ORM'lere yönelik ana itiraz, ORM uygulamasına tam olarak doğru SQL'i yazmak için güvenmememdi. Ve gördüğüm ORM'lere (çoğunlukla PHP kitaplıkları) bakılırsa, tamamen haklı olduğumu düşünüyorum.

Şimdi, web geliştirmemin çoğu Django kullanıyor ve dahil edilen ORM'yi gerçekten uygun buldum ve veri modeli ilk önce kendi terimleriyle ve yalnızca daha sonra SQL'de ifade edildiğinden, ihtiyaçlarım için mükemmel çalışıyor. Eminim bunu aşmak çok zor olmayacak ve elle yazılmış SQL ile desteklenmesi gerekmeyecektir; ancak CRUD erişimi için fazlasıyla yeterli.

NHibernate hakkında bilmiyorum; ama sanırım ihtiyacınız olan şeylerin çoğu için "yeterince iyi". Ancak diğer kodlayıcılar buna güvenmiyorsa; verilerle ilgili her hatada birincil şüpheli olacak ve doğrulamayı daha sıkıcı hale getirecek.

Bunu iş yerinizde kademeli olarak tanıtmayı deneyebilirsiniz, önce basit veri erişimi gibi küçük 'açık' uygulamalara odaklanın. Bir süre sonra prototiplerde kullanılabilir ve değiştirilemez ...

Bir OLAP veritabanıysa (örneğin, raporlama / analiz için kullanılan statik, salt okunur veriler, vb.), O zaman bir ORM çerçevesinin uygulanması uygun değildir. Bunun yerine, veritabanının saklı yordamlar gibi yerel veri erişim işlevselliğini kullanmak tercih edilir. ORM'ler işlem (OLTP) sistemleri için daha uygundur.

ORM kullanmamak için birçok iyi neden olduğunu düşünüyorum. Öncelikle ve en önemlisi, ben bir .NET geliştiricisiyim ve harika .NET çerçevesinin bana sağladığı şeye bağlı kalmayı seviyorum. Muhtemelen ihtiyacım olan her şeyi yapıyor. Bunu yaparak, daha standart bir yaklaşımla kalırsınız ve bu nedenle, aynı proje üzerinde çalışan başka bir geliştiricinin, orada olanı alıp onunla birlikte çalışabilmesi için çok daha fazla şans vardır. Microsoft tarafından halihazırda sağlanan veri erişim yetenekleri oldukça geniştir, bunları atmak için hiçbir neden yoktur.

10 yıldır profesyonel bir geliştiriciyim, çok sayıda çok başarılı milyon dolarlık projeye liderlik ettim ve hiçbir zaman herhangi bir veritabanına geçebilmek için gereken bir uygulama yazmadım. Neden bir müşterinin bunu yapmasını istedin? Dikkatlice planlayın, ihtiyacınız olan şey için doğru veritabanını seçin ve buna bağlı kalın. Kişisel olarak SQL Server, yapmam gereken her şeyi yapabildi. Kolay ve harika çalışıyor. 10 GB'a kadar veriyi destekleyen ücretsiz bir sürüm bile var. Oh, ve .NET ile harika çalışıyor.

Son zamanlarda veri katmanı olarak ORM kullanan birkaç proje üzerinde çalışmaya başlamak zorunda kaldım. Bunun kötü olduğunu düşünüyorum ve fazladan bir şey, sebepsiz yere nasıl kullanılacağını öğrenmek zorunda kaldım. Müşterinin veritabanlarını değiştirmeye ihtiyaç duyduğu delice ender durumlarda, tüm veri katmanını, ORM sağlayıcılarıyla dalga geçerek geçirdiğim zamandan daha kısa sürede kolayca yeniden çalışabilirdim.

Dürüst olmak gerekirse, bir ORM'nin gerçek bir kullanımı olduğunu düşünüyorum: SAP gibi, birden çok veritabanında çalıştırma yeteneğine gerçekten ihtiyaç duyan bir uygulama oluşturuyorsanız. Aksi takdirde bir çözüm sağlayıcı olarak, müşterilerime bu uygulamanın bu veritabanında çalışmak üzere tasarlandığını ve böyle olduğunu söylüyorum. Bir kez daha, 10 yıl ve sayısız uygulamadan sonra, bu hiç sorun olmadı.

Aksi takdirde, ORM'lerin daha azının daha çok olduğunu anlamayan geliştiriciler için olduğunu düşünüyorum ve uygulamalarında ne kadar havalı 3. parti araçlar kullanırlarsa, uygulamalarının o kadar iyi olacağını düşünüyorum. Bu gibi şeyleri zorlu uber meraklılarına bırakırken, bu arada herhangi bir geliştiricinin alabileceği ve hemen üretken olabileceği çok daha büyük bir yazılım geliştireceğim.

Çalışma zamanı performansı, düşünebildiğim tek gerçek dezavantaj, ancak bence bu, ORM'nin geliştirme / test etme / vb. İçin sizi kurtardığı zaman için adil bir değiş tokuştan daha fazlası. Ve çoğu durumda, veri darboğazlarını bulabilmeniz ve daha verimli olması için nesne yapılarınızı değiştirebilmeniz gerekir.

Hibernate'i daha önce kullanmadım, ancak birkaç "kullanıma hazır" ORM çözümüyle fark ettiğim bir şey esneklik eksikliği. Eminim bu, hangisiyle gideceğinize ve onunla ne yapmanız gerektiğine bağlıdır.

ORM'lerin endişe verici iki yönü vardır. Birincisi, başkası tarafından yazılan kodlardır, bazen kapalı kaynak, bazen açık kaynak ama kapsamı çok büyük. İkincisi, verileri kopyalarlar.

İlk sorun iki soruna neden olur. Yabancıların kodlarına güveniyorsunuz. Hepimiz bunu yapıyoruz, ancak bunu yapma seçimi hafife alınmamalıdır. Ya ihtiyacınız olan şeyi yapmazsa? Bunu ne zaman keşfedeceksin? ORM'nizin sizin için çizdiği kutunun içinde yaşıyorsunuz.

İkinci sorun, iki aşamalı işlemden biridir. İlişkisel veritabanı bir nesne modeline kopyalanmaktadır. Nesne modelini değiştirirsiniz ve veritabanını güncellemesi gerekir. Bu iki aşamalı bir işlemdir ve hata ayıklaması en kolay şey değildir.

ORM'lerin dezavantajlarının bir listesi için bu okumayı öneririm.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Kendim için, ORM'leri yazdığım çoğu uygulama için çok yararlı buldum!

/ Asger

Hibernate ile yaşadığım deneyim, anlambiliminin ince olması ve sorunlar olduğunda, kaputun altında neyin yanlış gittiğini anlamak biraz zor. Bir arkadaşımdan genellikle Criteria ile başladığını, sonra biraz daha fazla esnekliğe ve HQL'e ihtiyaç duyduğunu duydum ve daha sonra, ham SQL'e ihtiyaç duyulduğunu fark ettim (örneğin, Hibernate'in AFAIK birleşmesi yok).

Ayrıca ORM ile, insanlar kolayca mevcut eşleştirmeleri / modelleri aşırı kullanma eğilimindedir, bu da birçok özniteliğe sahip ve başlatılmamış bir nesnenin var olmasına yol açar. Dolayısıyla, sorgudan sonra, Hibernate işleminin içinde ek veri getirme işlemi gerçekleştirir ve bu da potansiyel bir yavaşlamaya neden olur. Ayrıca ne yazık ki, hazırda bekletme modeli nesnesi bazen görünüm mimarisi katmanına sızıyor ve sonra LazyInitializationExceptions görüyoruz.

ORM'yi kullanmak için, onu gerçekten anlamak gerekir. Ne yazık ki kimse kolay olmadığı halde kolay olduğu izlenimini edinir.

Kendi başına bir cevap olmak istemiyorum, yakın zamanda duyduğum bir alıntıyı yeniden ifade etmek istiyorum. "İyi bir ORM Yeti gibidir, herkes birinden bahseder ama kimse görmez."

Ellerimi bir ORM'ye koyduğumda, genellikle kendimi bu ORM'nin sorunları / sınırlamaları ile mücadele ederken buluyorum. Sonunda, evet, istediğimi yapıyor ve o berbat belgede bir yere yazılmıştı ama kendimi asla elde edemeyeceğim bir saat daha kaybederken buluyorum. Postgresql üzerinde nhibernate, sonra da akıcı nhibernate kullanan herkes ne yaşadığımı anlayacaktır. Sürekli "bu kod benim kontrolümde değil" duygusu gerçekten berbat.

Parmaklarımı işaret etmiyorum veya kötü olduklarını söylemiyorum, ancak CRUD'yi tek bir ifadede otomatikleştirmek için ne verdiğimi düşünmeye başladım. Şimdilerde ORM'leri daha az kullanmam gerektiğini düşünüyorum, belki minimumda db işlemlerini mümkün kılan bir çözüm oluşturmalı ya da bulmalıyım. Ama sadece benim. Bu ORM arenasında bazı şeylerin yanlış olduğuna inanıyorum ama bunu ifade edecek kadar yetenekli değilim.

ORM kullanmanın hala iyi bir fikir olduğunu düşünüyorum. Özellikle verdiğiniz durumu düşünürsek. Gönderinize bakılırsa, db erişim stratejileri söz konusu olduğunda daha tecrübelisiniz ve bir ORM kullanarak gündeme gelirim.

Sorguları kopyalayıp yapıştırmak ve metinde kodlama yapmak esneklik sağlamadığından # 1 için bir argüman yoktur ve # 2 için çoğu orm orijinal istisnayı sarar, oluşturulan sorguların izlenmesine izin verir, vb, bu nedenle hata ayıklama roket bilimi değildir.

Doğrulamaya gelince, bir ORM kullanmak ayrıca, herhangi bir yerleşik doğrulamanın yanı sıra doğrulama stratejileri geliştirmek için genellikle çok daha kolay zaman sağlar.

Kendi çerçevenizi yazmak zahmetli olabilir ve çoğu zaman bazı şeyler gözden kaçar.

DÜZENLEME: Bir noktaya daha değinmek istedim. Şirketiniz, kullanım ve uygulama için yönergeler ve uygulamalar geliştireceğiniz için değerini daha da artıran bir ORM stratejisi benimserse ve herkes seçilen çerçeve hakkındaki bilgilerini daha da artırarak gündeme getirdiğiniz sorunlardan birini hafifletir. Ayrıca, durumlar ortaya çıktığında neyin işe yaradığını ve neyin işe yaramadığını öğreneceksiniz ve sonunda çok fazla zaman ve emek tasarrufu sağlayacaktır.

Her ORM, hatta "iyi bir" bile, yazılımın verileri uygulama katmanınız ile veri deponuz arasında ileri geri iletmek için kullandığı temel mekaniklerle ilgili belirli sayıda varsayımla yüklenir.

Orta derecede karmaşık bir uygulama için, bu varsayımlar etrafında çalışmanın genellikle daha basit bir çözüm yazmaktan daha fazla zaman aldığını buldum: verileri sorgulamak ve yeni varlıkları manuel olarak başlatmak.

Özellikle, kodu indirdiğinizde ORM'nizin size sağladığı kullanışlı örneklerin kapsamı dışında kalan çok sütunlu anahtarları veya diğer orta derecede karmaşık ilişkileri kullanır kullanmaz aksaklıklarla karşılaşmanız olasıdır.

Belirli uygulama türleri için, özellikle çok sayıda veritabanı tablosu veya dinamik olarak oluşturulmuş veritabanı tablolarına sahip olanlar için, bir ORM'nin otomatik sihirli işleminin yararlı olabileceğini kabul ediyorum.

Aksi takdirde, ORM'lerin canı cehenneme. Şimdi bunların temelde bir moda olduğunu düşünüyorum.