Uygulamanın agnostik kalması gerçekten buna değer mi?

Şu anda Tomcat, Spring 4, Spring Security, MySQL ve Hibernate ile JPA kullanarak üzerinde çalışıyorum.

JPA'yı, ORM sağlayıcılarının altta yatan uygulamasının kesintisiz veya en azından daha az acı verici bir şekilde değiştirilmesini beklemek açısından seçtim. Bunun zihinsel olarak uygulama üzerindeki spesifikasyonları kullandığını söyleyebilirim (JAX-RS), Java geliştirme topluluğunun varsayılan noktasıdır.

Bu gerçekten yapmaya değer bir iş olup olmadığını merak ediyorum. Hibernate'i doğrudan kullanırsam, ana JPA spesifikasyonunun bir parçası olmayan özellikleri kullanabildiğim için biraz güç kazanacağımdan eminim.

Endişemin bir kısmı YAGNI fikrinden geliyor. Temelde belirli bir tarzda ve modda programlama yapıyorum (Hazırda Bekletme yerine JPA kullanarak), böylece gelecekte bir noktada ORM uygulamamı değiştirebilirim. Bunun, ürünün ömrü boyunca gerçekleşeceğinden şüphe duyuyorum, bu nedenle, esasen muhtemelen faydalarından asla yararlanamayacağım bir şeye çaba sarfediyorum.

Düşüncelerin nelerdir? JPA gibi şeyler söz konusu olduğunda "arayüze programlama" buna değer mi? Hiç bir üründe ORM uygulamasının tamamını değiştirdiniz mi? JPA sızıntısı gibi bir şeyden soyutlama işleminden tamamen kaçınabildiniz mi? Şahsen şimdiden tek bir yerel SQL çağrısına sahibim (veritabanı tablolarını temizlemek için) ve JPA spesifikasyonuna dahil edilmiş (bunun için yöntemlerin öneklerini al / ayarla ve ÜYE OF arasındaki fark) Sadece kendimi temel bir uygulamaya bağlayan IN / IN, kaçınmam için herhangi bir şansı doğurur.

Böylece gelecekte bir noktada ORM uygulamamı değiştirebilirim. Ürünün ömrü boyunca hiçbir zaman olacağından şüphe duyuyorum, bu nedenle, temel olarak faydalarından asla yararlanamayacağım bir şey için çaba sarf ediyorum

Tecrübelerime göre tipik kurumsal proje asla değişmiyor:

1. Veritabanı
2. ORM
3. Dil

Rakamları bilmiyorum, ancak uyguladığım ve daha sonra değiştirdiğim 2 katmanlı uygulamaların yüzdesi muhtemelen% 10'dan az olurdu. Bu gerçekleşirse, nadir görülür ve genellikle insanlar hala keşif modundayken projenin ilk 2-3 ayı içinde gerçekleşir. Bildiğim çoğu sistem 8-10 yıl sonra hala orijinal platformlarında çalışıyor.

Bir ORM'yi takas etmekten daha sık, daha fazla ne gördüğümü bilmek ister misiniz? Performans sorunları nedeniyle ORM'yi SQL'e düşürmek için tamamen kaldırma. Öyleyse ne olursa olsun, bu durumda, şeyleri yeniden yazacaksın.

Uygulama agnostiği için, onun bir efsanedir. Gerçekten aşağılama anlamına gelir. Yani benim yaklaşımım veri katmanını kucaklamak. Dilinizi ve tasarımınızı birinci sınıf bir parçası yapın. Daha mutlu, daha başarılı projeler için yapar.

buna değer mi?
Bu tamamen uygulamaya bağlı olacaktır.
Tek bir şirket için dahili bir uygulama yazıyorsanız, unut gitsin. Bu veritabanı, uygulamayı yıllarca, muhtemelen on yıllarca geride bırakacaktır.
Elbette, başlangıçta veritabanının yakın gelecekte başka bir şeyle değiştirilmesinin planlandığını anlamadığınız sürece.
Bunu, farklı veritabanı motorlarına sahip olabilecek müşterilere satış için yazıyorsanız, VE gereklilikleri, birden çok veritabanı motorunu desteklemesi gerektiği biçimindedir.

O zaman Java uygulamaları yazan çoğu insan için, büyük oranda alakasızdır.

Tecrübelerime göre: Hayır, JPA / Hibernate durumunda buna değmez .

JPA gibi şeyler söz konusu olduğunda "arayüze programlama" buna değer mi?

Öyle, ama özellikle JPA ile ilgisi yok. Hazırda Bekletme'nin "arabirimlere programlama" işlemini yapabilirsiniz. Bu, bir standardın altındaki bir çerçeveyi gizlemek değil, SOLID ile ilgilidir .

Hiç bir üründe ORM uygulamasının tamamını değiştirdiniz mi?

Evet ve hayır. Şirketimizin ürünlerinden biri kısmen Hazırda Bekletme'den jOOQ'a (JPA ile ilgisi olmayan) geçti. Tam olarak @codenheim'ın bahsettiği “tipik bir işletme projesi” değildi, bu yüzden takas mümkün oldu.

JPA uyumlu başka bir ORM ile Hazırda Bekletme modunu değiştirmenin hiçbir anlamı yok.

JPA sızıntısı gibi bir şeyden soyutlama işleminden tamamen kaçınabildiniz mi?

Hayır. Bu imkansız çünkü hem JPA hem de Hibernate çok karmaşık. Ve Hibernate'in performans sorunları ile de uğraşmanız ve yine de hataları tasarlamanız gerekiyor.

Burada sondaj karşıtlığı riski altında diyebilirim ki, evet, buna değer. Ve öyle değil.

Sorun, ORM'nizi veya veritabanı sağlayıcınızı böyle değiştirmede çok fazla değildir. Daha çok endişelerin ayrılması ve çevik kalması meselesidir.

Bir kütüphanenin bazı uygulama detaylarına güvenmeye başladığınızda, endişelerin daha derin ve daha derin dolaşmalarını yaratmaya başlarsınız.

ORM uygulamanızın Hazırda Bekletme olduğunu biliyorsanız, bu bilgi uygulamanızın bütün mimarisini izlemeye başlar. Hazırda Beklet veya JPA'nın yerini değiştiren yeni bir teknoloji ortaya çıktığında, Hazırda Bekletme'nin kendisinden önce gelenlere kadar iyice yaptığı gibi, bağımlılıkların beklediğinizden daha derinleştiğini görüyorsunuz.

Veritabanları ve işlemlerle uğraşmanın tüm karmaşıklıklarının, uygulamanın geri kalanı tarafından kolayca göz ardı edilebildiği yerde, modelinizi bir yerde sürdürmeme konusundaki tüm endişeleri ortadan kaldırmak daha iyidir. Bu uzak karanlık köşede, kendinizi isterseniz belirli uygulama detaylarına bağlayabilirsiniz - bu artık önemli değil.

Uygulama agnostisizmiyle ilgili sorun, bir geliştirici olarak zamanında boşa harcayacağınız zamandır.

Arayüze çok fazla zaman harcadığımız, daha sonra hiç bir zaman yeni bir şekilde kullanılmayan, hiç dönüştürülmemiş ve sadece 'olduğu gibi' yıllarca kullanılmayan birkaç proje yazdım.

Ayrıca, hiç kimsenin dönüştürülmesi gerekmeyen bir yazılım dönüştürme zamanını da boşa harcadım.

Yapmam gereken tek gerçek gözlem, eskisinin çok daha az acı verici olduğu.