ORM'ler zengin alan modelleri oluşturmayı mümkün kılıyor mu?

Hibernate'i yaklaşık 8 yıl boyunca projelerimin çoğunda kullandıktan sonra, kullanımını engelleyen ve uygulamaların yalnızca DB ile depolanan prosedürler aracılığıyla etkileşime girmesini isteyen bir şirkete indim.

Bunu birkaç hafta yaptıktan sonra, oluşturmaya başladığım uygulamanın zengin bir etki alanı modeli oluşturamadım ve uygulama sadece (korkunç) bir işlem komut dosyası gibi gözüküyor.

Bulduğum bazı konular:

• Saklı yordamlar yalnızca minimum miktarda veri yüklediğinden, nesne grafiği gezinilemiyor, bu da bazen farklı alanlara sahip benzer nesnelerimiz olduğunu gösteriyor. Bir örnek: tüm verileri müşteriden almak için saklı bir prosedürümüz var, diğeri ise hesap bilgilerini ve müşteriden birkaç alanı almak için.
• Mantığın çoğu yardımcı sınıflarda sona ermektedir, bu nedenle kod daha yapılandırılmıştır (eski C yapıları olarak kullanılan varlıklar ile).
• Daha sıkıcı iskele kodu, sonuç kümelerini saklı bir yordamdan ayıklayan ve bir varlık içine koyan hiçbir çerçeve olmadığı için.

Benim sorularım:

• Herhangi biri benzer bir durumda mıydı ve mağaza prosedürü yaklaşımına katılmıyor mu? ne yaptın?
• Saklı yordamları kullanmanın gerçek bir yararı var mı? aptal noktadan başka "hiç kimse bir damla tablo yayınlayamaz".
• Saklı yordamları kullanarak zengin bir etki alanı oluşturmanın bir yolu var mı? DAO'ları / Depoları nesne grafiği üzerinde gezinmek için varlıklara enjekte etmek için AOP kullanma olasılığının olduğunu biliyorum. Bu seçeneği sevmedim, çünkü vudu yakın.

Sonuç

İlk olarak, cevaplarınız için hepinize teşekkür ederim. Geldiğim sonuç, ORM'lerin Zengin Etki Alanı modellerinin oluşturulmasını sağlamadığı (bazı kişilerin söylediği gibi), ancak (genellikle tekrarlayan) çalışma miktarını basitleştirdiğidir. Aşağıdaki, sonucun daha ayrıntılı bir açıklamasıdır, ancak herhangi bir katı veriye dayanmamaktadır.

Çoğu uygulama, diğer sistemlere bilgi talep eder ve gönderir. Bunu yapmak için, model terimlerinde bir soyutlama yaratırız (örneğin bir iş etkinliği) ve etki alanı modeli olayı gönderir veya alır. Etkinlik genellikle modelden küçük bir bilgi alt kümesine ihtiyaç duyar, ancak tüm model için değil. Örneğin, bir çevrimiçi mağazada, bir ödeme ağ geçidi bir kullanıcı için ücret talep etmek için bazı kullanıcı bilgilerini ve toplamı ister, ancak satın alma geçmişi, kullanılabilir ürünler ve tüm müşteri tabanını gerektirmez. Dolayısıyla, etkinliğin küçük ve özel bir veri kümesi var.

Bir uygulamanın veritabanını harici bir sistem olarak alırsak , Etki Alanı Modeli varlıklarını veritabanına eşleştirmemizi sağlayan bir soyutlama oluşturmamız gerekir ( NimChimpsky'nin dediği gibi , bir veri eşleyicisi kullanarak). Açık olan fark şu ki, her bir model varlık için veritabanına bir harita oluşturmaya ihtiyacımız var (ya eski bir şema ya da saklı yordamlar), ikisi eşzamanlı olmadığından, bir etki alanı parçasının kısmen eşleşebileceği için fazladan acı çekiyor. Bir veritabanı varlığına (örneğin, yalnızca kullanıcı adı ve şifreyi içeren bir UserCredentials sınıfı) diğer sütunlara sahip bir Kullanıcılar tablosuna eşlenir) veya bir etki alanı modeli öğesi birden fazla veritabanı varlığına (örneğin bire bir varsa) eşlenebilir masada bir eşleme, ancak tüm verileri sadece bir sınıfta istiyoruz).

Birkaç varlığa sahip bir uygulamada, varlıkları çaprazlamak gerekmiyorsa, fazladan iş miktarı az olabilir, ancak varlıkları geçmek için şartlı bir ihtiyaç olduğunda artar (ve böylece bir çeşit tembel uygulamak isteyebiliriz) Yükleniyor'). Bir uygulama daha çok varlığa sahip olmak için büyüdükçe, bu çalışma artar (ve doğrusal olmayan bir şekilde arttığı hissine sahibim). Buradaki varsayım, bir ORM'yi yeniden icat etmeye çalışmadığımızdır.

Veritabanını harici bir sistem olarak ele almanın bir yararı, içinde çalışan bir uygulamanın 2 farklı versiyonunu istediğimiz durumları kodlayabilmemizdir. Bu, üretime sürekli teslimat senaryosunda daha ilginç hale geliyor ... ama bunun ORM'lerle daha az ölçüde mümkün olduğunu düşünüyorum.

Veritabanına erişimi olmasa bile, bir geliştiricinin bir sistemde depolanan tüm bilgileri almasa bile, yalnızca kötü amaçlı kodları enjekte ederek (ör. Müşterilerin kredi kartı detaylarını kaydeden satırı kaldırmayı unuttuğuma inanamıyorum, sevgili lordum! ).

Küçük güncelleme (6/6/2012)

Saklı yordamlar (en azından Oracle'da) Sıfır kesinti süresinde sürekli teslimat gibi bir şey yapmayı önler, çünkü tabloların yapısındaki herhangi bir değişiklik prosedürleri ve tetikleyicileri geçersiz kılar. Böylece, DB güncellenirken, uygulama da azalacaktır. Oracle, Sürüme Dayalı Yeniden Tanımlama adı verilen bir çözüm sunar , ancak bu özellik hakkında sorduğum birkaç DBA, bunun kötü bir şekilde uygulandığını ve üretim DB'sine koymadıklarını belirtti.

Başvurunuz hala alan odaklı tasarım ilkelerinden modellenmelidir. Bir ORM kullanıp kullanmadığınızı, düz JDBC'yi, SP'leri (ya da her neyse) çağırmak önemli olmamalıdır . Umarım modelinizi SP'lerden soyutlayan ince bir katman bu durumda hile yapmalıdır. Başka bir afişte belirtildiği gibi , SP'leri ve sonuçlarını bir hizmet olarak görmeli ve sonuçları etki alanı modelinizle eşlemelisiniz.

Saklı yordamları kullanmanın gerçek bir yararı var mı?

Finans dünyasında (ve Sarbanes-Oxley uyumluluğunun gerekli olduğu yerlerde ), yapmaları gerekeni yapmalarını sağlamak için sistemleri denetleyebilmeniz gerekir. Bu gibi durumlarda, tüm verilere erişim saklı yordamlar aracılığıyla olduğunda uyumu sağlamak çok daha kolaydır. Ve tüm geçici SQL kaldırıldığında, bir şeyleri gizlemek çok daha zordur. Bunun neden "iyi bir şey" olacağına bir örnek olarak, sizi Ken Thompson'ın Trusting Trust üzerine Düşünceler adlı klasik makalesine yönlendiririm .

Saklı yordamlar, istemci tarafı SQL kodundan çok daha verimlidir. DB'de bazı optimizasyonlar yapmasına izin veren önceden derlerler.

Mimari olarak, bir SP, bir görev için gerekli olan minimum veriyi geri gönderir; bu, daha az veri aktarıldığı için iyidir. Eğer böyle bir mimariye sahipseniz, DB'yi bir servis olarak düşünmeniz gerekir (bunu bir web servisi olarak düşünün ve her SP'yi çağırmanın bir yöntemidir). Bu şekilde çalışmak sorun olmamalı, ORM ise sanki yerel verilermiş gibi uzak verilerle çalışmanıza rehberlik ediyor, bu yüzden dikkatli değilseniz performans sorunlarının ortaya çıkmasını sağlamanız için sizi kandırıyor.

SP'leri tamamen kullandığımız durumlarda, DB bir veri API'si sağladı ve kullandık. Bu özel uygulama çok büyük ölçekli ve şaşırtıcı derecede iyi bir performans sergiledi. SP'lerden sonra söylenen kötü bir şey söylemeyeceğim!

Başka bir avantaj var - DBA'lar sizin için tüm SQL sorgularınızı yazacak ve DB'deki tüm ilişkisel hiyerarşiyi mutlu bir şekilde ele alacaktır, bu yüzden de zorunda değilsiniz.

Sık sık olan şey, geliştiricilerin ORM nesnelerini etki alanı modelleri olarak yanlış kullanmalarıdır.

Bu yanlıştır ve etki alanınızı doğrudan DB şemanıza bağlar.

Gerçekten olması gereken, alan adlarını istediğiniz kadar zengin ve ORM katmanını ayrı olarak kullanın.

Bu, her nesne kümesi arasında eşlemeye ihtiyaç duyacağınız anlamına gelir.

Etki alanı nesneleriniz, Hazırda Beklet işlevini kullanmak için gerekli olmadıkça, lütfen doldurulabilir. Bence uygun terim veri haritasıdır . Kalıcı verilerinizin etki alanı nesnelerinizden tamamen farklı bir yapıya sahip olması çok olasıdır.