Yeni bir Java kalıcılık aracı hakkında ne düşünürdünüz, bu gerçekten bir ORM değil mi? [kapalı]

Java'da kalıcılık

Son yıllarda, EJB 2.0, Hibernate, JPA ve evde yetiştirilenler gibi kavramları kullanarak Java'da kalıcı soyutlama alanında deneyim kazandım. Bana dik bir öğrenme eğrisi ve çok karmaşıklık varmış gibi geldi. Buna ek olarak, SQL'in büyük bir hayranı olarak, birçok soyutlama modelinin SQL üzerinde çok fazla soyutlama sağladığını, çok iyi kavramlar olan, ancak SQL değil "ölçütler", "tahminler", "kısıtlamalar" gibi kavramlar yarattığını düşündüm.

Java'daki kalıcı soyutlama soyut fikri RDBMS'nin bir şekilde OO dünyasıyla eşleştirildiği Nesne-ilişkisel modele dayanıyor gibi görünmektedir. ORM tartışması her zaman duygusal bir tartışma olmuştur, çünkü böyle bir çözüm var olsa bile herkese uyan tek bir çözüm var gibi görünmemektedir.

jOOQ

ORM ile ilgili sorunlardan nasıl kaçınılacağına dair kişisel tercihim, ilişkisel dünyaya bağlı kalmaktır. Şimdi veri modeli paradigması seçimi, kişisel bir tercih olduğu için tartışma konusu olmamalı veya hangi veri modelinin somut bir soruna en uygun olduğu meselesi olmamalıdır. Başlamak istediğim tartışma, jOOQ adlı kendi inat aracımın etrafında . Modern kalıcılık araçlarının avantajlarının çoğunu sağlamak için JOOQ tasarladım:

• SQL tabanlı Etki Alanına Özel Dil
• Temel veritabanı şemasını Java ile eşleyen kaynak kodu oluşturma
• Birçok RDBMS desteği

Birkaç modern kalıcılık aracının sahip olduğu bazı özellikler eklemek (yanlışsam beni düzelt):

• Karmaşık SQL desteği - sendikalar, iç içe seçimler, otomatik birleştirme, kenar yumuşatma, durum cümleleri, aritmetik ifadeler
• Standart olmayan SQL desteği - saklı yordamlar, UDT'ler, ENUMS, yerel işlevler, analitik işlevler

Daha fazla bilgi için lütfen dokümantasyon sayfasını göz önünde bulundurun: http://www.jooq.org/learn.php . Linq yalnızca SQL için tasarlanmamış olmasına rağmen, Linq için C # 'da çok benzer bir yaklaşımın uygulandığını göreceksiniz.

Soru

Şimdi, SQL'in büyük bir hayranı olduğumu söyledikten sonra, diğer geliştiricilerin jOOQ (veya Linq) için heyecanımı paylaşıp paylaşmayacağını merak ediyorum. Kalıcı soyutlamaya bu tür bir yaklaşım uygulanabilir mi? Görebileceğiniz avantajlar / dezavantajlar nelerdir? JOOQ'yu nasıl geliştirebilirim ve fikrinizde eksik olan nedir? Kavramsal veya pratik olarak nerede yanlış yaptım?

Kritik ama yapıcı cevaplar takdir ediliyor

Tartışmanın duygusal bir tartışma olduğunu anlıyorum. Dışarıda benzer şeyleri yapan birçok harika araç var. İlgilendiğim şey, kendi deneyimlerinize veya okuduğunuz makalelere dayanarak kritik ancak yapıcı geri bildirimdir .

Bence doğru yoldasınız ve çözümünüze devam etmeniz gerekiyor. Önceki eleştirilerden bazıları aşırı sert, ancak bazı geçerli noktalar belirtiliyor.

Ben de ihtiyaçlarımı karşılayacak tam özellikli bir ORM çözümü için uzun ve zor aradım, ancak baktığım her çözüm kısa çıktı. Her birinin artıları ve eksileri vardır, ancak hiçbiri istediğim her şeyi yapmamıştır. Bu çözümlere yönelik eleştirilerinize katılıyorum - yani genel olarak karmaşık ve dik bir öğrenme eğrisi var.

En iyi yarışmacı fiili standart Hibernate olmalı. Tam özellikli, sağlam ve iyi test edilmiş. Buna saygı duyuyorum ve ne olduğu için minnettarım. Şimdi, programlama topluluğunun yarısını ihlal etme riski altında, bunun şişirilmiş ve karmaşık bir performanssız kod parçası olduğunu da söylemeliyim. Bağırsaklarında dolaşmak, hata ayıklamak ve anlamaya çalışmak için oldukça fazla zaman geçirdim ve gördüklerimden etkilendim. Söyledikten, ben hala iyi bir ORM arayan herkes için başlangıç ​​noktası olarak tavsiye ederim. Basit CRUD'de mükemmeldir, ancak veri madenciliği veya numara kırma gibi performans toplu sorguları için kullanmam.

Ne yazık ki, benim uygulama sayı crunching çeşididir (bazı CRUD olmasına rağmen), bu yüzden kendi rulo almaya karar verdim. Başından beri diğer çözümlere kıyasla daha düşük olacağını biliyordum, ama yeterince iyi olacak ve bana ihtiyacım olan performansı verecektim. Şimdi gerçekten harika olan kısım: çözümünüze çok benziyor!

En doğru yaptığınızı düşünüyorum: Temel inançlarınızı bir tür görev ifadesi olarak söylediniz ve bu inançlar doğrudur. Açıkçası bu problemi düşünmek için oldukça fazla zaman harcadım ve çözmesi zor. Ancak zaman geçtikçe, programlama topluluğunun onu daha iyi anlamaya geldiğini düşünüyorum ve daha iyi çözümler üreteceğiz. Önceki tüm çabaları (özellikle Hazırda Bekletme) için Kudos, ama bence daha iyisini yapabiliriz.

Çözümünüz sorunu daha iyi düzeltir, ancak yalnızca bir kısmını çözer. Bence katmanlı bir yaklaşım bize istediğimiz herşeyi verebilir. / IMO ile karşılaştığınız temel katman. Önerdiğiniz gibi, bu katmanın en iyi otomatik olarak bir veritabanı şemasına göre oluşturulduğunu düşünüyorum. Doğrudan veritabanına eşlenen ve artık olmayan çok basit bir ilişkisel nesne modeli olmalıdır. Verilerin koddan çok daha uzun süre devam etmesini sağlıyorsunuz, bu nedenle veriler kod yönlendirmeli, tersi değil. Performanslı toplu sorgulamanın yanı sıra CRUD'yi de destekleyecektir. Muhtemelen bu katmana bir çeşit L1 önbellek uygularım.

Bununla birlikte, diğer ORM çözümlerinin başarılı olduğu şey, nesnelerinizi temeldeki veritabanının gerçek yapısına çok fazla bağlı olmayan bir şekilde tanımlama yeteneğidir. Bu işlev için başka bir katman oluştururdum. Zorunlu olarak bu katman daha soyut, umarım daha basit hale gelir (kayıp işlevsellik pahasına) ve bir önceki katman üzerine kurulur. L2 önbellek kullanabilir.

Daha fazla katmana açığım, ancak benim için kilit nokta, kütüphaneye birden fazla giriş noktası sağlayarak her ihtiyacı karşılayabileceğiniz. Doğrudan seçtikleri nesnelere eşlenen basit bir CRUD çözümü isteyenler için, üst katman üzerine inşa edebilirler. Daha güçlü ve performanslı bir şey arayan ancak ek karmaşıklığa katlanmak isteyenler için alt katmana takılabilirler. Özel bir sorgu dili oluşturmaz, bunun yerine sorgu oluşturucu nesnesini bu amaçla ortaya koyarım. Kod katmanlı olduğundan, bu işlevsellik doğal olarak özel geçiş olmadan var olur.

Sanırım alanı anlıyorsunuz ve tekerleği yeniden icat etmiyorsunuz, aksine biraz farklı bir nişe vurdunuz. Ve açıkçası, bu yine de iyileştirmeyi kullanabilen bir tekerlek. Geçmişin güç merkezlerine karşı zorlu bir savaşla karşı karşıyasınız, ancak çözümünüz iyi ise ve bence bu yönde ilerliyorsa, kendi avantajlarında popülerlik kazanacaktır.

"Orada çok fazla sihirli mermi var ve saf geliştiricilerin sıkıntısı yok."

Suçlama yok, görünüşe göre bu alanda ne yapıldığını tamamen anlamıyorsunuz ve bu nedenle bazı tekerlekleri yeniden keşfediyorsunuz - deneyim bize, icat ettiğiniz tüm tekerleklerin temiz ve eğlenceli olsa da neredeyse iyi veya zaten mevcut güzel rafine tekerlekler olarak yararlı.

Bu tür bir API'yi uygun hale getirecek bir senaryo, ORM'nin çoğunun sahip olmanıza izin vermediği bir veritabanı agnostik SQL oluşturucusuna ihtiyacınız olduğundadır. İhtiyacım olan büyük bir durum da Raporlar oluşturmak. Nesne yönelimli bir şekilde SQL oluşturmak ve test için çeşitli veritabanlarında bu sql çalıştıracak ihtiyacım var. Hazırda bekletme ve diğer ORM, yapılandırmalara çok bağımlıdır, böylece sql yapımı, xmls'de ilişkilendirmenin olmadığı tabloyu birleştiremediğim şekilde sınırlandırırım. Geliştirdiğim Rapor Modülünde herhangi bir ilişkilendirme mümkün olduğundan, farklı bir şey aramıştım. Sonra JOOQ ile karşılaştım. Sadece sorunumu çözdü. Sadece salt okunur bir erişime ihtiyacım var, hazırda bekletme gibi acı verici hata ayıklama sorunları ile asla karşılaşmam.

Aslında ortak POJO yolu yerine veri modelleme için farklı bir yol geliştirmek ve JOOQ SQL oluşturmak için bir katman olan temel biri olarak kullanmayı planlıyorum. Bu yüzden JOOQ'nun üstünde, HashMaps kullanarak verileri / varlıkları modellemenin daha esnek bir yolunu oluşturmayı planlıyorum. Tasarımım, yukarıdaki yorumların söylediği gibi, çerçeveyi tamamlamak için çeşitli katmanları kullanmamıza rağmen, ön uç ve arka uç tasarımını bir giriş noktasına daha kolay entegre etmeyi mümkün kılacaktı. JOOQ gerçekten kendi projemde olduğu gibi çok iyi bir rol oynayacak, vakıflardan veya sütunlardan biri olarak hizmet ediyor.

Yani iyi iş lukas devam edin!

Aracınızı doğru bir şekilde anlarsam, Nesneleri eşlemek yerine doğrudan kavramsal bir SQL çerçevesiyle eşler. SQL işleviyle (ORM) bazı eşleştirme uygulayan nesneleri, neredeyse daha fazla geeky kontrolü için ORM-- soyutlaması gibi, böylece daha fazla SQL özelliği kullanabilirsiniz ORM genellikle size vermez mi?

Hangi sorunu çözmeye çalıştığınızdan emin değilim. Aracınız derinlemesine SQL bilgisi gerektirdiğinden, insanlar sadece SQL'i kullanmaz mı? Kurtulmaya çalıştığınız tutkal kodu mu? SQL sorgularının basit dizeler yerine API modellemesi ile daha iyi doğrulanması?

JOOQ örneklerinizin SQL'in LISP sürümlerine benzediğini itiraf etmeliyim. Bu kötü bir şey değil :) ve bazı gelişmiş şeylerin ilginç olduğunu görmüyorum, ancak listelediğiniz avantajlar gittikçe ilerledikçe yavaş yavaş kayboluyor (daha fazla yapılandırma, daha az soyut, belirli SQL'in iç kutsallığında daha köklü motor vb.)

Çoğu ORM'de özlediğimi görmek istediğim bir öneri Nesnelerle ilişkisel olmayan bir şekilde başa çıkabilen, Nesne etkileşimlerini arka ucun ne olabileceğine çeviren bir çerçevedir (SQL, NoSQL, Konu Haritaları, RDF, vb. SQL etkileşimleri, lehçeler ve ilişkisel düşünme özellikleri yerine kullanılan Modelin önbelleğe alınmasını gerektirir .

IMHO, elbette. :)