ORM tarafından veritabanı soyutlamanın kullanılmasının faydaları nelerdir? [kapalı]

Seçtiğim çerçeve tarafından önerilen ORM'yi kullanmaya başladım ve ORM'nin sağladığı soyutlama katmanı fikrini sevsem de, bunun gerçekten ne anlama geldiğini anlamaya başlıyorum. Bu artık benim veritabanı (mysql) ile çalışmıyorum ve herhangi bir mysql özgü özellikleri yok gibi pencereden dışarı gitti anlamına gelir.

ORM'nin fikri, her şeyi veritabanı agnostik hale getirerek bana yardım etmeye çalışmasıdır. Bu harika görünüyor, ancak genellikle belirli bir veritabanı sistemini seçmem için bir neden var. Ancak veritabanı agnostik yoluna giderek ORM en düşük ortak paydayı alır, bu da en küçük özellik setiyle (tüm veritabanları tarafından desteklenenler) sonuçlandığım anlamına gelir.

Ya uzun vadede temel veritabanını değiştirmeyeceğimi bilsem ne olur? Neden veritabanına özgü özelliklere de erişmiyorsunuz?

Ben de aynı şekilde görüyorum. Gerektiğinde altına girmenize izin vermeyen herhangi bir soyutlama kötülüktür, çünkü kodunuzdaki her türlü çirkin soyutlama tersine yol açar.

İş yerinde, oldukça iyi çalışan, kendi geliştirdiğimiz bir ORM var, ancak özelliklerinin açıkça sağlamadığı bir şeye ihtiyaç duyduğumuz zamanlar için, bir dize alıp doğrudan oluşturduğu sorguya bırakan bir yöntem var. gerektiğinde ham SQL kullanımı için.

Bu özelliğe sahip olmayan herhangi bir ORM, derlendiği bitlere değmez.

ORM en düşük ortak paydayı alır

İfadenize katılmıyorum. Örnek olarak nHibernate'i ele alacağım . Bu çerçeve, çoğu ORM gibi, sürüme (ve desteklenen özelliklere) bakılmaksızın, en popüler olanlar da dahil olmak üzere birçok veritabanını destekler.

Kısa not: Yalnızca veritabanı soyutlamasından bahsedersiniz. Bu birçok faydadan biri, ama gerçekten nesne yönelimli özelliklerin daha güçlü olduğunu düşünüyorum (örneğin: kalıtım). Ve You design your domain model first...

... soyutlamaya geri dönelim. En düşük ortak payda değil. In nhibernate , sen lehçeleri var. Farklı veritabanlarını sorgulamak için aynı kodu kullanmanızı sağlar. Lehçeler sizin için özellik yönetimiyle ilgilenir. Doğru ifade şudur a given dialect will try to use all the power of a given database system.

Bir örnek olarak SqlServer2005, tanıtıldığında yeni SQL Server 2005 sayfalama özelliklerinden yararlandığı lehçesini alın . Bu lehçeyi kullanmak yerine SqlServer2000performanslarınızı artırdınız.

Tabii ki istisnalar var, ancak nHibernate ile çalışırken uzun yıllar boyunca tek bir tanesiyle karşılaşmadım ve uygulamalarım çok veri merkezlidir.

Fikir düzgün, ama ben hiç bir ORM aracı kullanmak noktasına taşındı. SQL'i kendim yazmak (veya kullanılan depolama alanını işlemek) benim için bir sorun değildi. Ancak, daha uzun ürün ömrüne sahip daha az sayıda proje üzerinde çalışma lüksüne sahibim, bu yüzden el kodlu SQL ve DB manipülasyonu yerinde olduğunda, yerinde. Ayrıca, işleminizi ORM aracının düşünme biçimine sığdırmak zorunda kalmadan ihtiyacınız olan doğrudan SQL sorgularını işleyebilirsiniz.

Yani, sanırım soruların birine girmeden önce olması gerekir:

Sen gerçekten misin onları kullanmaktan bir şey kazanıyor ? Yani, kullanmaya değer hale getirmek ve sisteminize ekstra bir komplikasyon eklemeye değer bir ORM aracı uygulayarak yeterli miktarda çaba harcıyor musunuz? (bu, özellikle ekstra 'parçanın' artık potansiyel destek sorunları için ekstra bir vektör olduğu ticari uygulamalar için geçerlidir)

Ve sonra, ekstra soyutlama katmanının uygulama üzerinde olumsuz bir etkisi olacak mı? El kodlu SQL'den daha yavaş olacak mı, vb.

O / RM düzenli olarak eleştirilmektedir. Ted Neward bunu birkaç yıl önce " Bilgisayar Bilimi Vietnamı" olarak adlandırdı . O / RM

iyi başlar, zaman geçtikçe daha karmaşık hale gelir ve uzun bir süre önce kullanıcılarını net bir sınırlama noktası, net kazanma koşulları ve net bir çıkış stratejisi olmayan bir taahhütle yakalar.

Sadece kendi ad-hoc eşlemenizi yazmadığınız sürece (diğerlerinin söylediği gibi birçok durumda iyi bir çözümdür), ilişkisel olmayan veritabanı kullanma gibi alternatiflere bakabilirsiniz. Bazıları gerçekten bir nesne veritabanı daha iyi olduğunu söylüyor, bu bağlamda bahsedilen diğer buzzwords LINQ, Ruby ve Tutorial D olduğunu düşünüyorum. Sanırım, gerçekten ilişkisel veritabanlarının aksine, gerçekten nesne veritabanları vardır. Ancak pratikte, kavramsal veri modellemesinin - yani, gerçek dünyadaki nesneleri hangi hakkında depolamak istediğinizi ve bu nesnelerin birbirleriyle nasıl ilişkilendiğini bulmak için - kavramsal modelin sizi programlama veya veritabanı dili.

Alternatif nedir?

Bu ilginç bir kavram. Temel veritabanının özelliklerini soyutlayarak, belirli veritabanı uygulamasının bazı özelliklerini kesinlikle kaybediyoruz. (Belirli veritabanı özelliklerine bağlı olsak da olmasak da başka bir argüman) Sanırım bu, belirli özelliklere erişmenize izin veren veritabanına özgü ORM'ler tarafından çözülebilir, ancak bu değerden ve sorundaki bir adımdan daha fazla sorun olabilir yanlış yön.

Günün sonunda, kendine sormalısın - alternatif nedir?

ORM'leri kullanmayı bırakmalı ve tüm veritabanı erişimini kendimiz yazmaya geri dönmeli miyiz? Elbette ORM aracılığıyla birkaç veritabanı özelliğine erişimimizi kaybedebiliriz, ancak her zaman eski okul tekniklerini kullanarak bunlara erişebilirsiniz. Sonuçta üretkenlikte elde ettiğiniz kazançlar dezavantajlardan tamamen ağır basmaktadır.

Bir ORM temel olarak " Yüklenmemiş Prosedürler " dir. Orada bir terim buldum.

Bir ORM'nin yaptığı her şey, Görünümler, Tetikleyiciler ve Saklı Yordamlarla çoğaltılabilir. Ham SQL'in soyutlanmasına yardımcı olurlar ve normalleştirilmiş veritabanlarını tutarlı tutabilirler. Ancak sadece basit durumlar için iyi çalışır. İşlenecek çok fazla makine verisi varsa, bunlar bir performans tahliyesi haline gelebilir. (SQL oluşturucu zincirleri her şeyi soyutlayamadığından, PHP'deki ORM'ler genellikle komut dosyası tarafını alır.)

Ancak her zamanki gibi, her şey eldeki uygulamaya ve göreve bağlıdır.

ORM'leri kullanarak acı veren bir şey, hayranlarının çoğunun artık SQL ve RDB teorisini bilmemize gerek olmadığını iddia etme eğiliminde olmasıdır. Sonuçlar komikten tamamen felakete değişir. Ve bu, ORM'in ürettiği ve uzmanlarının milyonlarca kez olmasına rağmen, bir ORM'yi doğru bir şekilde kullanmak ve yapılandırmak için SQL ve RDB teorisini iyi bilmemiz gerektiğini belirtiyor .

İnsanlar neden tüm bağlamları büyülü, evrensel olarak uygulanabilir bir gümüş mermi haline getirmeyen birçok araç üzerinde kullanımı olan bir aracı benim üstümde.

Geçen yıl sık sık değişen bir şirket içi uygulama üzerinde çalıştım ve bir ORM kullandığımız için çok mutlu oldum. Uygulama, bir değişiklik yönetimi ekibi için destekleyici bir uygulamadır ve daha büyük proje geliştikçe, küçük uygulamamız, var olmayan ve birkaç ay önce öngörülemeyen durumlar için yeni gereksinimler aldı.

ORM ( PHP'de Propel ) sayesinde, kod için mantığın bir kısmını ayırdık, bu nedenle bir işlev, sorgunun "kayıt geçerli" bölümünü, başka bir güvenlik bölümünü (" bu yeteneklere sahiptir "), ... Temel yapı değiştiyse (" kayıt geçerliliği "için dikkate alınması gereken fazladan bir alan), yirmi SQL yan tümcesini değil, yalnızca bir işlevi değiştirmek zorunda kaldık.

Tüm (iyi, çoğu) SQL yan tümcelerinin ayrı bir XML dosyasında saklandığı bir durumdan geldik, böylece "veritabanı değişikliklerinin işlenmesi kolay olacaktır". İnan bana, değildi. Bir kısmı o kadar korkunçtu ki , Daily WTF'ye göndermek zorunda kaldım .

Bir sorgu Propel Kriterleri ile ifade edilemeyecek kadar karmaşıksa veya satıcıya özgü bazı özelliklere (MySQL kullandığımızdan beri tam metin araması) ihtiyaç duyuyorsak, bu Propel ile ilgili bir sorun değildi. Özel ölçütler ekleyebilirsiniz veya gerçekten gerektiğinde ham SQL kullandık ( şimdi gerçek Propel nesneleriyle birleştirmek daha da kolay ). Üreticiye özgü eklentilerinizi oluşturulan sınıflara kolayca ekleyebilirsiniz, böylece her iki dünyanın da en iyisine sahip olursunuz: uygulama kodunuzda SQL yok, ancak veritabanı motorunuzun tüm özellikleri.

Ama asıl mesele veritabanından uzakta programlamak, yani veritabanındaymış gibi düşünmenize gerek yok.

Şimdi C # çalışmak ve LINQ çok, çok ve akıcı yöntemler çok kullanın. Nesnelerimin program düzeyinde nasıl saklandığını, bulunduğunu, hatta kaydedildiğini ve iş katmanı düzeyinde çok az olduğunu düşünmem gerekmiyor.

Çoğunlukla Belirli Veritabanları tarafından sağlanan yöntemler DB Bağlayıcısı'nda kullanılır, böylece bu optimizasyonları ne olduklarını bilmenize gerek kalmadan alırsınız.

Hala DB tarafı işlevleri yazabilirsiniz. Genellikle bunları eşleştirebilirsiniz.

Ve her şeyden önce, böyle ayırma, test edilebilirliğe izin verir ve sizi (biraz) daha iyi yapılandırılmış kod yazmaya zorlar

ORM'ler veritabanına özgü özelliklere de erişmenizi sağlayabilir , hangi ORM'yi kullandığınıza ve sağladığı özelliklere bağlıdır.

Örneğin, üzerinde çalıştığım projede Java Kalıcılık API'sını ve Hazırda Bekletme modunu kullanıyoruz. Buna rağmen, soundex içeren tablolarda arama yapmak gibi veritabanına özgü birkaç özellik kullanıyoruz.

Benim için, bir ORM kullanmanın ana yararı, bir uygulama veritabanını agnostik hale getirmesi değil (her ne kadar iyi bir şey olsa da), ancak çoğu zaman şeylerin nasıl saklandığını ve alınan.

Bununla birlikte , bir noktada, başvurunuzun gereksinimlerine bağlı olarak, büyük olasılıkla bunu düşünmeniz gerekir. ORM sihir değildir.

Kendimi yazdım, bu da seçim yapmamı ve eklememi kolaylaştırıyor.

Evey db'ye özgü bir şey var. Sadece kütüphane bana yardımcı olan sorguyu yazmak gerekiyor (yerine '?' Ve params yerine bir parametre adı ve kullanımı .Add kullanabilirsiniz)

Sanırım benim yarısı yarı yararlı. ORM dünyasında yardım alıyorum ve sorgu dünyasında önemli parçalar yapıyorum.

Satır içi veya kaydedilmiş procları eklemek ve seçmek, güncellemek ve bunları DAL üzerinden eşlemek için kod yazmak daha uzun bir normdur, sadece istisnai durumlarda faydalıdır. Mevcut ORM'ler, destekleyici veritabanları ve diller sormanız gereken soru ORM'yi neden kullanmıyorsunuz?

Bunlar standartlaştırılmış, evrenseldir, belirtilmiş veya jeneriktir. ayrıca uygulanması daha hızlı ve kolaydır. Sesaltı, linq-sql ve varlık çerçevesi kullandım. Geliştiricinin veritabanı eşlemesi yerine mantığa ve iş kurallarına odaklanmasını sağlar.

Benim (basit) iki sentim:

1: ORMS ve ORMS vardır. Bazı ORMS, Active Record'a, bazıları da Veri Eşleyici'ye dayanır - bu kendi başına ilgili bir husustur, ancak sonuçları anlamak için biraz araştırma gerektiren bir konudur. Genel olarak - PHP benim deneyim ORMS eski destek, az destek ikincisi. Aktif Kayıt tabanlı ORM'lerin iki etkiden biri var gibi görünüyor - ya veritabanını normalleştirmiyorlar ya da nesne etkileşimlerini desteklemek için çok sayıda sınıf çağırıyorlar.

2: ORM'lerin avantajı, çalıştırmanız gereken sorgunun karmaşıklığı ile doğrudan ilişkili olarak azalır. Güzel ve basit bir ilişkiniz olduğunda - örneğin Kullanıcılar -> Yayınlar, çok iyi çalışabilirler. Çoğu ORM / çerçevenin bunun gibi örnekleri kullanmasının nedeni budur (IMO). Bununla birlikte, karmaşık sorgular çalıştırmanız gerektiğinde, oluşturmanız gereken ORMQL miktarı, normal bir SQL sorgusunun dize uzunluğu ile karşılaştırılabilir - ancak sorguyu çalıştıran nesne grafiği sayesinde daha az performans gösterir; soyutlama. Kısacası, ORM'ler veritabanı görevlerinizin ilk% 30-50'si için mükemmeldir ancak sonuncusu için korkunçtur. Bence bu AR'nin bu kadar yaygın olmasının bir başka nedeni.

3: Neden veritabanından gizlenelim? Javascript'i soyutlamak için bir sunucu tarafı dili kullanır mısınız?

Şahsen ben bu yaklaşımları karıştırıyorum:

• "kullanıcılar" ı yükleyerek temel bilgiler için ORM kullanın
• önceden hazırlanmış birkaç SQL sorgusu içeren bir DAO kullanın (örn. selectLike, selectWhere).
• daha spesifik ancak yeniden kullanılabilir özel sorgular eklemek için DAO'yu gerektiğinde genişletin
• Bir kerelik sorguları yürütmek için DAO - yani $ data = Dao-> sorgusu (sql dizeniz) aracılığıyla basit veritabanı erişimi sağlayın.

Tüm bunları söyledikten sonra, Doctrine 2 yakında çıkacak ve bu gerçekten ilginç görünüyor.

Sql özelliklerini kullanmak istiyorsanız myBatis gibi SQL eşleyici çerçevelerini kullanabilirsiniz.