Neden ORM kullanmalısınız? [kapalı]

Bir ORM'nin "avantajlarına" motive olursanız ve yönetim / müşteri için neden ORM'yi kullanırsınız, bu nedenler nelerdir?

En iyi neden olarak hangisinin oylandığını görebilmemiz için yanıt başına bir nedeni tutmaya çalışın.

Veri erişimini daha soyut ve taşınabilir hale getirmek. ORM uygulama sınıfları, satıcıya özgü SQL yazmayı bilir, bu nedenle sizin yapmanız gerekmez.

ORM kullanmanın en önemli nedeni, zengin, nesne odaklı bir iş modeline sahip olabilmeniz ve yine de onu depolayabilmeniz ve ilişkisel bir veritabanına karşı hızlı bir şekilde etkili sorgular yazabilmenizdir. Benim bakış açıma göre, iyi bir ORM'nin yazabileceğiniz gelişmiş sorgu türleri dışında diğer oluşturulan DAL'larla karşılaştırıldığında size sağladığı gerçek avantajlar görmüyorum.

Düşündüğüm sorgu türlerinden biri polimorfik bir sorgu. Basit bir ORM sorgusu, veritabanınızdaki tüm şekilleri seçebilir. Geri bir şekil koleksiyonu elde edersiniz. Ancak her örnek, ayırt edicisine göre bir kare, daire veya dikdörtgendir.

Başka bir sorgu türü, tek bir veritabanı çağrısında bir nesneyi ve bir veya daha fazla ilgili nesneyi veya koleksiyonu hevesle getiren bir sorgu olabilir. Örneğin, her şekil nesnesi, tepe noktası ve yan koleksiyonları doldurulmuş olarak döndürülür.

Buradaki pek çok kişiye katılmadığım için üzgünüm, ancak kod oluşturmanın tek başına bir ORM ile gitmek için yeterince iyi bir neden olduğunu düşünmüyorum. ORM'lerin yaptığı kavramsal veya performans ek yüküne sahip olmayan kod üreteçleri için birçok iyi DAL şablonu yazabilir veya bulabilirsiniz.

Veya, bir ORM kullanmak için iyi SQL yazmayı bilmenize gerek olmadığını düşünüyorsanız, yine katılmıyorum. Tekli sorgu yazma açısından bir ORM'ye güvenmenin daha kolay olduğu doğru olabilir. Ancak, geliştiriciler sorgularının ORM ve çevrildikleri SQL ile nasıl çalıştığını anlamadıklarında, ORM'ler ile zayıf performans gösteren rutinler oluşturmak çok kolaydır.

Birden çok veritabanında çalışan bir veri katmanına sahip olmak bir avantaj olabilir. Yine de o kadar sık ​​güvenmek zorunda olduğum bir şey değil.

Sonunda, deneyimlerime göre, ORM'nizin daha gelişmiş sorgu özelliklerini kullanmıyorsanız, kalan sorunları daha az öğrenme ve daha az CPU döngüsü ile çözen başka seçenekler de olduğunu yinelemek zorundayım.

Oh evet, bazı geliştiriciler ORM'lerle çalışmayı eğlenceli buluyor, bu nedenle ORM'ler de geliştiricilerinizi-mutlu tutma perspektifinden iyi. =)

Hızlı gelişme. Örneğin, sorgu sonuç alanlarını nesne üyeleriyle eşlemek gibi tekrarlayan kodu ortadan kaldırmak ve bunun tersi de geçerlidir.

Veri erişim katmanınızda iş kurallarının OO kapsüllenmesini destekler. İş kurallarını, hantal tetik ve saklı yordam dilleri yerine tercih ettiğiniz uygulama dilinde yazabilir (ve hata ayıklayabilirsiniz).

Temel CRUD işlemleri için standart kod üretiliyor. Bazı ORM çerçeveleri veritabanı meta verilerini doğrudan inceleyebilir, meta veri eşleme dosyalarını okuyabilir veya bildirim temelli sınıf özelliklerini kullanabilir.

Bir soyutlama geliştiriyorsunuz çünkü farklı veritabanı yazılımlarına kolayca geçebilirsiniz.

Böylece nesne modeliniz ve kalıcılık modeliniz eşleşir.

Gelişim mutluluğu, IMO. ORM, SQL'de yapmanız gereken pek çok çıplak metal şeyi özetler. Kod tabanınızı basit tutar: yönetmek için daha az kaynak dosya ve şema değişiklikleri saatlerce bakım gerektirmez.

Şu anda bir ORM kullanıyorum ve geliştirmemi hızlandırdı.

Basit SQL sorgularının yinelenmesini en aza indirmek için.

Araştırmamın nedeni VS2005'in DAL araçlarından (şema eşleme, TableAdapters) üretilen koddan kaçınmaktır.

Bir yıldan uzun bir süre önce oluşturduğum DAL / BLL, başka biri üretilen işlevlerden bazılarından yararlanmak için kullanmaya başlayana kadar (ki orada olduğunu bilmiyordum) iyi çalışıyordu (onu inşa ettiğim şey için)

DAL / BLL çözümünden çok daha sezgisel ve temiz bir çözüm sağlayacak gibi görünüyor. http://wwww.asp.net adresindeki

Kendi SQL Command C # DAL kod oluşturucumu oluşturmayı düşünüyordum, ancak ORM daha zarif bir çözüme benziyor

Sorguların derlenmesi ve test edilmesi.

ORM'lerin araçları geliştikçe, derleme zamanı hataları ve testleri yoluyla sorgularınızın doğruluğunu daha hızlı belirlemek daha kolaydır.

Sorgularınızı derlemek, geliştiricilerin hataları daha hızlı bulmasına yardımcı olur. Sağ? Sağ. Bu derleme, geliştiricilerin artık yalnızca SQL veya SQL benzeri ifadeler yerine iş nesnelerini veya modellerini kullanarak kodda sorgular yazması nedeniyle mümkün olmuştur.

NET'te doğru veri erişim modellerini kullanıyorsanız, sorgu mantığınızı bellek koleksiyonlarına karşı birim testi yapmak kolaydır. Bu, testlerinizin yürütülmesini hızlandırır çünkü veritabanına erişmeniz, veritabanında veri kurmanız ve hatta tam kapsamlı bir veri bağlamı döndürmeniz gerekmez. [DÜZENLE] Bu, birim olarak düşündüğüm kadar doğru değil bellekte test etmek zor zorluklar yaratabilir üstesinden gelinmesi gereken . Ancak yine de bu entegrasyon testlerini yazmayı önceki yıllara göre daha kolay buluyorum. [/ EDIT]

Bu, sorunun sorulduğu birkaç yıl öncesine göre bugün kesinlikle daha alakalı, ancak bu yalnızca deneyimlerimin yattığı Visual Studio ve Entity Framework için geçerli olabilir. Mümkünse kendi ortamınızı ekleyin.

SQL'i zamanın% 95'inden uzaklaştırın, bu nedenle ekipteki herkesin veritabanına özel süper verimli sorgular yazmayı bilmesine gerek kalmaz.

Burada pek çok iyi nokta olduğunu düşünüyorum (taşınabilirlik, geliştirme / bakım kolaylığı, OO iş modeline odaklanma vb.), Ancak müşterinizi veya yönetiminizi ikna etmeye çalışırken, bunların tümü kullanarak ne kadar tasarruf edeceğinize bağlıdır. bir ORM .

Tipik görevler (veya hatta yaklaşan büyük projeler) için bazı tahminler yapın ve (umarız!), Geçiş için göz ardı edilmesi zor birkaç argüman alırsınız.

kod smith şablonlarını kullanan .net katmanları

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Neden aynı zamanda üretilebilecek bir şeyi kodlayın?

Değişiklikler geldiğinde ne kadar zamandan / paradan tasarruf edeceğinizi ve ORM aracı bunu sizin için yapacağından SQL'inizi yeniden yazmak zorunda kalmayacağınızı onlara ikna edin

Bence bir dezavantajı, ORM'nin POJO'nuzda biraz güncellemeye ihtiyaç duyacağıdır. esas olarak şema, ilişki ve sorgulama ile ilgilidir. bu nedenle, model nesnelerinde değişiklik yapmanızın beklenmediği senaryo, proje veya s / b istemci ve sunucudakinden daha fazlası arasında paylaşıldığı için olabilir. bu nedenle bu gibi durumlarda, ek çaba gerektirecek şekilde iki seviyeye bölmeniz gerekecektir.

Ben bir android geliştiricisiyim ve bildiğiniz gibi mobil uygulamaların boyutu genellikle çok büyük değildir, bu nedenle saf model ve orm-etkilenen modeli ayırmaya yönelik bu ek çaba, tam anlamıyla değmez.

Bu sorunun genel bir soru olduğunu anlıyorum. ancak mobil uygulamalar da genel bir şemsiyenin içine giriyor.