Hazırda Bekletme Neredeyse Kariyerimi Nasıl Mahvetti?

Yayınlanan: 2022-03-11

Bir Java geliştiricisi olduğunuzu ve bir sonraki büyük projenize başlamak üzere olduğunuzu hayal edin. Projenin geri kalanı için size bağlı kalacak temel kararları vermeniz gerekir. Düz SQL ile uğraşmak istemediğiniz için esnek veri modelinizin en iyi nesne yönelimli soyutlamasını seçmek istiyorsunuz. Her türlü veriyi ve ideal olarak her türlü veri tabanını desteklemek istiyorsunuz.

Açık cevap, sadece Hibernate kullanmaktır, değil mi? Java geliştiricilerinin %90'ı sizinle aynı fikirdedir, ancak bu onu doğru karar mı yapar?

Hazırda Beklet'i kabul edilen standart olduğu için körü körüne kullanırsanız nelerin yanlış gidebileceğine bir göz atalım.

Bir Java geliştiricisi olan Monica'yı düşünün. Monica kısa süre önce mimar rolüne terfi etti ve şimdi şirketinde yeni bir ürün için teknoloji yığınını hazırlamaktan sorumlu. Java dünyasında veritabanı iletişimini yönetmek için tek bir iyi araç olduğunu biliyor: Hazırda Bekletme . Hazırda Bekletme , iyi bilinen ve desteklenen bir JPA standardıdır. Ancak, bir projeye başlamadan önce birkaç şeyi kontrol etmek her zaman iyi bir fikirdir. Neyse ki meslektaşı Ben doğru adamı tanıyor.

Hazırda Bekletme, Gümüş Bir Kurşun Gibi Sesler

4 yıl önce

Ben - Merhaba Monica, John'u tanıştırmak istiyorum. O bir Hazırda Bekletme uzmanı ve size yardım edecek.

Monica - Hey John, bana zaman ayırdığına sevindim. Yani, Sonraki Büyük Şeyimizi inşa ediyoruz, bilirsiniz. Bir sonraki Facebook veya Google olmayı planlıyoruz. Yoğun günler. Çok büyük olacak. Kesinlikle harika! Herkes çok heyecanlı! Bir mimar rolüne terfi ettim, bu yüzden şimdi kullanacağımız yığını seçmem gerekiyor. Eksik olan tek şey sebat…

John - Hazırda Beklet !

Monika - Evet! Kesinlikle! Sadece ne düşünüyordum! Bizim için mükemmel bir eşleşme ve gerçek anlaşma gibi görünüyor. Gerçek bir kurumsal sorun için piyasada kanıtlanmış ve uzun bir geçmişe sahip gerçek bir kurumsal çözüm. Bununla ilgili çok olumlu deneyimler duydum. Ancak takım arkadaşlarımızdan biriyle bir sorunum var; buna tamamen karşıdır. Veritabanları hakkında çok şey biliyor ve uygulamamız ile veritabanı arasına başka bir katman eklemekten korkuyor. O süper zeki ve onu bunun iyi bir karar olduğuna ikna etmek için gerçekten iyi argümanlara ihtiyacım var. Bana bununla yardım edebilir misin?

John- Elbette! memnuniyetle karşılayacağım. Hazırda Bekletme , gerçekten de olağanüstü bir araçtır. Bankalar gibi büyük, gerçek kurumsal çözümlerde yaygın olarak kullanılmaktadır. Yanlış gidemezsin. Kalıcılığı düşünün: Hazırda Beklet öğesini seçin. Java ile yazıyorsanız, bu kesinlikle doğru seçimdir, ayrıca diğer diller için portlarınız vardır. Bakın kaç iş tanımı bunu gerektiriyor!

Monica - Kesinlikle katılıyorum! Bu konuda aynı hislere sahibim. Önceki bir projede, çoğunlukla SQL'i düz eski JDBC aracılığıyla kullanıyorduk. Saçma! Biliyorum! Ama olay şu: Takımda gerçekten zeki SQL adamlarımız var ve Hibernate tarafından oluşturulan SQL'i gördüklerinde gerginleştiler. Çirkin ve okunamaz görünüyordu; bu ileride sorun olur mu?

John - Bak. DBA adamlarının farklı bir bakış açısı var. Hazırda Beklet'ten korkuyorlar çünkü projedeki rollerinin yerini alıyor gibi görünüyor. Ayrıca, veritabanlarında yerleşik sorgu iyileştiriciler bulunur, bu nedenle bu sorguların gerçekte nasıl görüneceği konusunda endişelenmenize gerek yoktur. Veritabanı sizin için optimize edecektir. Her şey SQL'in yapamadığı hızlı geliştirme ile ilgilidir.

Monica - Gerçekten mi?! Artık SQL ile uğraşmıyor musunuz? Harika! Bir DBA'nın haftalarca bazı sorguları optimize etmeye çalıştığı son sefer. Haftalar! Oh, bunu sana söylerken çok utandım ama… saklı prosedürler kullandığımızı biliyor muydun (gülüyor). Ah, çok karışıktı. Projenin hala onu kullandığına inanabiliyor musunuz? Dışarıdaki insanlar için çok üzülüyorum. Hala bu sıkıcı kodu tekrar tekrar yazmak zorundalar. Hala bir Java veya SQL projesi olup olmadığını merak ediyorum.

John - Bu tam olarak nesne yönelimli yaklaşım ile ilişkisel yaklaşım arasındaki farktır. Bu sözde nesne yönelimli empedans uyumsuzluğudur. Hazırda bekletme bu boşluğu kapatabilir. Geliştiriciler, iş mantığı oluşturmaya odaklanabilir. Push özellikleri, paydaşları ve tüm yönetimi mutlu eder. En önemli şeyleri yapın: İş! Çok sayıda ortak kod kaybolacak ve mantık ile veriler arasında sihirli, görünmez ama güvenilir bir bağlantınız olacak.

Monica - Karşılıklı işbirliği. Tam sinerji. Sanki veritabanı en başından beri dilin bir parçasıydı. Bu teknolojik inanç sıçramasının lideri olduğum için çok mutluyum. Yazılım yolculuğundaki warp hızı gibi.

John - Evet! Sende var!

Monica - Aman Tanrım, çok heyecanlıyım! Teşekkürler John! Ben hazırım!

Hazırda Bekletme gümüş bir kurşun değildir. Bunu varsayılan veritabanı çözümünüz olarak görmeyin.
Cıvıldamak

Esnek Olmayan Çözümlerle Büyüyen Ağrılar

3 yıl once

Monica - Hey John, geçen yıl konuştuğumuz projeyi hatırlıyor musun?

John - Tabii. Nasıl gidiyor?

Monica - Yakında üretime geçeceğiz. Her şey yolunda, ancak bazı sorular ortaya çıktı.

John - Tabii, vur bana.

Monica - Artık veritabanı şemamızı sıfırdan oluşturamıyoruz. Veri kaybetmeden şema değişikliklerini desteklemenin en iyi yolu nedir?

John - Öncelikle, Hazırda Bekletme , üretim geçiş aracı olarak kullanılmak üzere tasarlanmamıştır. FlywayDB veya Liquibase gibi bir şey kullanın. Oldukça basit. Geçiş komut dosyalarını yazarsınız, ardından hazırda Bekletme eşlemeleriyle birlikte varlık modelini güncellersiniz, böylece gerçek veritabanı yapısıyla senkronize olur.

Monica - Hmm, anlıyorum. Önceki projede sadece düz SQL geçişi kullanıyorduk.

John - Bu da iyi. Varlık modelini ve şemayı senkronize tuttuğunuz sürece, istediğiniz gibi yapın.

Monica - anlıyorum. Başka bir şey var. Her zaman tembel/istekli getirme sorunları ile mücadele ediyoruz. Bir noktada, her şeyi hevesle yapmaya karar verdik, ancak yetersiz görünüyor ve ayrıca bazen oturum olmadığı için bazı alanlara erişmek mümkün olmuyor veya bunun gibi bir şey. Bu normal mi?

John - Hazırda Bekletme hakkında daha fazla bilgi edinmeniz gerekiyor. Veritabanından eşleme yapmak kolay değildir. Temel olarak, bunu yapmanın birden fazla yolu vardır. Sadece sizin için işe yarayan bir yol seçmeniz gerekiyor. Tembel alma, size bu nesneleri isteğe bağlı olarak yükleme yeteneği verir, ancak etkin bir oturum içinde çalışmanız gerekir.

Monica - Son dağıtım için hangi veritabanı motorunu kullanacağımız konusunda hâlâ mücadele ediyoruz. Hazırda Bekletme'nin taşınabilir olduğunu düşündüm, ancak bazı MS SQL sihri kullanan bazı yerel sorgularımız var ve aslında üretimde MySQL ile gitmek istiyoruz.

John - Hazırda Bekletme , bağımsız ölçütler veya HQL kullandığınız sürece size esneklik sağlar; herhangi bir yerel sorgu, çözümünüzü veritabanına bağlar.

Monica - O zaman MS SQL'e bağlı kalmamız gerekiyor gibi görünüyor. Son soru: Takım arkadaşım HQL'de "limit" anahtar kelime olmadığını söyledi. Şaka yapıyor sandım ama ben de bulamadım. Bu aptal soru için üzgünüm…

John - Gerçekten de, HQL'de "limit" bir anahtar kelime yoktur. Veritabanı satıcısına özel olduğu için bunu sorgu nesnesi aracılığıyla kontrol edebilirsiniz.

Monica - Diğer tüm öğelerin HQL'de olması garip görünüyor. Boşver. Zaman ayırdığınız için teşekkürler!

İlgili: Çok Kiracılı Bir Uygulama Nasıl Oluşturulur: Hazırda Bekletme Eğitimi

SQL Çözümlerini Şimdi Yeniden Birlikte Hackliyoruz

2 yıl önce

Monica - John, başlangıçta SQL ile uğraşmayacaktık ama şimdi mecburuz gibi görünüyor. İhtiyaçlarımız artıyor ve bunun başka bir yolu yok gibi görünüyor. Yanlış geliyor ama SQL'i her gün yeniden kullanmaya başladık.

John - Eh, yanlış değil. En başta veritabanına odaklanmanıza gerek yoktu. Ancak proje büyüdükçe SQL kullanmak ve performans optimizasyonu üzerinde çalışmak iyidir.

Monica - Bazen günlerimizi hata arayarak geçiririz. Hazırda Bekletme ile oluşturulan SQL'i analiz etmemiz gerekiyor gibi görünüyor çünkü neden beklendiği gibi çalışmadığı ve beklenmedik sonuçlar ürettiği hakkında hiçbir fikrimiz yok. Hazırda Bekletme hata izleyicisinde iyi bilinen bazı sorunlarla karşılaştık. Ek olarak, varlık modelini senkronize halde tutarken uygun geçişler yazmak zordur. Hazırda Bekletme dahili özellikleri hakkında çok şey öğrenmemiz ve nasıl çalışacağını tahmin etmemiz gerektiğinden zaman alıcıdır.

John - Her zaman bir öğrenme eğrisi vardır. Çok fazla yazmanıza gerek yok, ancak nasıl çalıştığını bilmeniz gerekiyor.

Monica - Daha büyük veri kümeleriyle çalışmak da can sıkıcı. Son zamanlarda, veritabanına büyük bir ithalat yaptık ve bu çok yavaştı. Sonra daha hızlı hale getirmek için oturumu temizlememiz gerektiğini öğrendik. Öyle olsa bile, hala önemli ölçüde daha yavaş, bu yüzden onu düz SQL ifadeleri olarak yeniden yazmaya karar verdik. Komik olan şu ki, düz SQL yazmak aslında bunu yapmanın en hızlı yoluydu, bu yüzden son seçeneğimiz olarak bunu yapmaya karar verdik.

John - İçe aktarma, nesne yönelimli bir süreç değildir. Hazırda Bekletme , nesne yönelimli tasarıma odaklanır. Yerel sorguları her zaman kullanabileceğinizi unutmayın.

Monica - Hazırda Bekletme önbelleğinin nasıl çalıştığını anlamama yardım eder misin? Sadece anlamıyorum. Bazı birinci/ikinci düzey önbellekler var. Bu ne hakkında?

John - Tabii. Kalıcı verilerin sözde işlem düzeyinde önbelleğidir. Sınıf sınıf ve koleksiyon bazında bir küme veya JVM düzeyinde önbellek yapılandırmak mümkündür. Kümelenmiş bir önbellek bile takabilirsiniz. Ancak, önbelleklerin kalıcı mağazada başka bir uygulama tarafından yapılan herhangi bir değişikliğin farkında olmadığını unutmayın. Ancak, süresi dolmuş önbelleğe alınmış verileri düzenli olarak silmek üzere yapılandırılabilirler.

Monica - Üzgünüm, kötü bir gün geçirdiğimi düşünüyorum. Bunu biraz daha açıklayabilir misin?

John - Tabii. Bir nesneyi save , update , saveOrUpdate veya load , get , list , iterate veya scroll yoluyla almak için her ilettiğinizde, bu nesne oturumun dahili önbelleğine eklenir. Nesneyi ve koleksiyonlarını birinci düzey önbellekten de kaldırabilirsiniz.

Monica - Eee...

John - Ayrıca, önbellek modlarını kontrol edebilirsiniz. Öğeleri ikinci düzey önbelleğe okumak ve yazmak için normal modu kullanabilirsiniz. İkinci seviyeden okumak için get modunu kullanın ancak geri yazamazsınız. get ile aynı olan put kullanın, ancak ikinci seviyeden okuyamazsınız. Ayrıca, ikinci seviyeye yazacak, ancak ondan okumayacak ve use minimal puts özelliğini atlayacak, veritabanından okunan tüm öğeler için ikinci seviye önbelleği yenilemeye zorlayacak olan refresh modunu da kullanabilirsiniz.

Monica - anlıyorum. Tamam. Bunu bir düşüneyim. Ah, geç oldu, gitmem gerek. Zaman ayırdığınız için teşekkürler!

John - Rica ederim!

Hazırda Bekletmeden Vazgeçmek

2 hafta önce

Monica - John, yeni bir yazılım geliştirme çağına girdiğimizi sanıyordum. Bir ışık yılı atlayışı yaptığımızı sanıyordum. Ancak aradan dört yıl geçmesine rağmen hala aynı sorunlarla uğraşıyoruz gibi görünüyor, sadece farklı bir açıdan. Hazırda Bekletme mimarisi, yapılandırma, günlük kaydı, adlandırma stratejileri, tuplizerler, varlık adı çözümleyicileri, gelişmiş tanımlayıcı oluşturucular, tanımlayıcı oluşturucu optimizasyonu, birlik-alt sınıflar, XDoclet biçimlendirme, dizine alınmış koleksiyonlarla çift yönlü ilişkilendirmeler, üçlü ilişkiler, idbag, örtük polimorfizmi karıştırmayı öğrenmem gerekiyordu. diğer miras eşlemeleri, iki farklı veri deposu arasında nesne çoğaltma, ayrılmış nesneler ve otomatik sürüm oluşturma, bağlantı serbest bırakma modları, durumsuz oturum arabirimi, koleksiyon kalıcılığının sınıflandırması, önbellek seviyeleri, tembel veya istekli getirme ve çok daha fazlası. Bildiğim her şeye rağmen, kötü bir şekilde başarısız olmuşuz gibi görünüyor. Bu bir yazılım fiyaskosu! Nihai başarısızlık! Felaket! Armagedon!

John- Bekle! Ne oldu?

Monica - Bir çıkmaza girdik. Uygulama performansımız gülünç derecede yavaş! Rapor almak için iki gün beklememiz gerekiyor! Bir müşteri için bir gösterge panosu oluşturmak için iki gün. Bu, gösterge tablomuz giderek daha eski hale gelirken, her gün hesaplama kuyruğumuzu artırmamız gerektiği anlamına geliyor. DBA uzmanımız bazı sorguları optimize etmek için iki aydır çalışıyor, veritabanı yapımız ise tam bir karmaşa. Onu destekleyen geliştiriciler var, ancak sorun şu ki DBA SQL'de düşünüyor ve geliştiriciler bunu bağımsız kriterlere veya HQL formatına çevirmek için günlerce harcıyorlar. Performans şu anda çok önemli olduğu için mümkün olduğunca yerel SQL kullanmaya çalışıyoruz. Her neyse, veritabanı şeması yanlış göründüğü için fazla bir şey yapamıyoruz. Nesne yönelimli bakış açısından doğru geldi, ancak ilişkisel açıdan gülünç görünüyor. Kendime soruyorum: Bu nasıl oldu? Geliştiriciler bize varlık yapısını değiştirmenin çok büyük bir çaba olacağını söylüyorlar, bu yüzden bunu karşılayamayız. Önceki projede bir karışıklık olduğunu hatırlıyorum, ama asla bu kadar kritik bir noktada durmadık. Verilerle çalışmak için tamamen farklı bir uygulama yazabildik. Şimdi, varlık modelinin her zaman düzgün davranacağından emin olmak gerçekten zor olduğundan, oluşturulan bu tabloları değiştirmek risklidir. Ve bu en kötü kısım bile değil! Performansı artırmak için sadece veritabanı sorunlarını değil, veritabanımız ile uygulama arasındaki tüm katmanla ilgili sorunları da çözmemiz gerekiyor. Bu çok zor! Bu yeni adamlarımız var, bilirsiniz, danışmanlar. Verileri çıkarmaya, başka bir depoya koymaya ve ardından dışarıdan hesaplamalar yapmaya çalışıyorlar. Hepsi çok fazla zaman alıyor!

John- Ne diyeceğimi bilmiyorum.

Monica - John'u görüyorsun; Seni suçlamak istemiyorum. Tüm bu sorunları çözmek için Hazırda Beklet'i seçtim, ancak şimdi bunun bir gümüş kurşun olmadığını öğrendim. Hasar verildi ve geri döndürülemez. Aslında size bir şey sormak istiyorum: Kariyerimin son dört yılını Hibernate işleriyle uğraşarak geçirdim. Şu anki şirketimde bir geleceğim yok gibi görünüyor. Bana yardım eder misiniz?

Peki Alınan Ders Ne?

Bugün

John - Hey, Peter, Monica'yı tanıtmama izin ver.

Peter - Hey, Monica! Bildiğiniz bir sonraki büyük şeyimizi inşa ediyoruz. Çok büyük olacak! Uber gibi olmak istiyoruz! Belki de ne kadar sebat biliyor musun…

Monica - Hazırda Bekletme Değil!

Sarmak

Monica bir Hazırda Bekletme uzmanıdır. Ancak, bu durumda Hazırda Bekletme yanlış bir karardı. Çözümünün orijinalinden daha büyük bir soruna dönüştüğünü keşfettiği an, tüm proje için en büyük tehditti.

Veri, uygulamanın temel amacıdır ve beğenin ya da beğenmeyin, tüm mimariyi etkiler. Hikayeden öğrendiğimiz gibi, sadece Java uygulamanız bir veritabanı kullandığı için veya sosyal kanıt nedeniyle Hazırda Bekletme modunu kullanmayın. Esnekliği kucaklayan bir çözüm seçin. JdbcTemplate veya Fluent JDBC Wrapper gibi sağlam JDBC sarmalayıcılar için birçok seçenek vardır. Alternatif olarak, jOOQ gibi başka güçlü çözümler de vardır.