Bağımlılık enjeksiyon çerçeveleri bir bağımlılık riski oluşturuyor mu?

Bağımlılık enjeksiyonunu kullanmak için mevcut bir sistemi yeniden düzenledim ve bu iş sorunsuz ilerliyor.

Bir süre sonra çok sayıda kurum içi kütüphanenin kullandığım DI çerçevesine bağımlı hale geldiğini fark ettim. Sonuç olarak, tüm proje şimdi bu üçüncü taraf çerçevesine dayanmaktadır.

Tüm bağımlılıkları ortak bir kütüphaneye bağımlı hale getirerek bir ironi gördüm.

İlk tepkim bağımlılık çerçevesi etrafında bir sarıcı kitaplığı oluşturmaktı. Bu nedenle, gerekirse bu çerçeveyi değiştirebilirim. İlgili çalışmayı tahmin ettikten sonra ortaya çıkan API'nin mevcut çerçeveye benzer olacağını fark ettim ve bu nedenle değiştirmeyi daha zor hale getireceğim. Bu yüzden fikri terk ettim.

Benim endişem, kullandığım DI çerçevesinin eski hale gelmesi veya değiştirilmesi gerekiyor.

DI ile çalışırken bir proje ile DI çerçevesi arasındaki bağlantıyı azaltan bir geliştirme modeli var mı?

Tamamen haklısınız - bir DI çerçevesi kullanmak büyük olasılıkla kodunuzu o şeyden bağımlı kılacaktır. Aslında, bu çok şaşırtıcıdır, çünkü bu genellikle diğer tüm çerçeveler veya vakıf kütüphaneleri için geçerlidir, özellikle bu lib projenizi kodunuzun herhangi bir yerinde kullanılan bazı genel özelliklerle desteklediğinde. Örneğin, belirli bir kullanıcı arabirimi çerçevesini veya Web çerçevesini kullanmaya karar verdiğinizde, söz konusu kitaplığa dayalı olarak belirli miktarda kod oluşturduğunuzda bu kararın daha sonra değiştirilmesi zordur. Belirli (belki de standart dışı) bir Stringsınıf kullanmaya karar verdiğinizde , daha sonra bu kararı kolayca değiştiremezsiniz. Böyle bir karar mimari bir karardır, belirli bir programlama dilini seçmek gibidir ve> 100K kod satırı yazdıktan sonra bu kararı değiştirmeye çalışmaktır.

Kodunuzun tümünün belirli bir çerçeveye bağlı olması, ondan beklediğiniz şeyi yaptığı ve gerektiği gibi korunduğu sürece sorun olmayabilir. Ancak durum böyle değilse bir sorun haline gelebilir. Bu durumla nasıl başa çıkılacağı konusunda bazı stratejiler var:

• birkaç yıl boyunca size güncellemeler ve yeni sürümler sunabileceğine inandığınız bir satıcıdan bir çerçeve seçin

• yeterli sayıda kod satırı (ve uygun bir lisans) olan açık kaynaklı bir çerçeve seçin, böylece satıcı pazardan kaybolursa, kendi başınıza herhangi bir bakım yapabilirsiniz

• kendi çerçeveni yaz

• satıcı müsait olduğu sürece durumla yaşayın ve gerçekten yok olduğunda, farklı bir çerçeve seçin ve yeni çerçeveyi kullanarak eski çerçeveyi taklit eden bir adaptör oluşturmaya çalışın.

Önceden bir sarıcı kitaplığı oluşturma fikri hiç de yeni değil, ancak nadiren çalıştığını gördüm, çünkü gelecekteki bir durum için size çarpıp çarpmayacağını veya ne zaman çarpacağını ve ne yapacağını bilmediğiniz için varsayımlar yapmanız gerekecekti. "yeni" çerçeve gibi görünecek. Öte yandan, birkaç yıl önce, yukarıda bahsettiğim adaptör stratejisini uygulayarak ~ 120K kod satırı ile bir C ++ projesinde tam bir UI çerçevesini başarıyla değiştirdik.

Sıradan yapıcı enjeksiyonu hiç bir çerçeve gerektirmez. Kaybettiğiniz tek şey, bir yapılandırma dosyasındaki bağımlılıklarınızı merkezileştirme yeteneğidir.

DI kapları, nesne grafiği çok büyük ve karmaşık olduğunda kullanılan bir "kurumsal yazılım" kalıbıdır. Uygulamaların% 95'inin gerektirmediğinden şüpheleniyorum.

DI çerçevelerinin yakın zamanda gerçekten eski olabileceğini sanmıyorum. Eski yapmak için ne olmalı?

• Yeni ve daha akıllı bir modelin icadı belki? Bununla birlikte, kodda çok daha büyük değişiklikler gerektirecektir.
• Dilde bir değişiklik olabilir mi? Daha da kötüsü.

Mevcut DI'nin yeterince olgun olduğunu söyleyebilirim ve orada çok fazla şey olduğunun farkında değilim. Dilinizi belirtmediniz, bu yüzden Guice'den bahsetmişken , oldukça rahatsız edici değildir ve standart Java ek açıklamalarıyla çalışır (ayrıca standartlaştırılmamış şeyler için kendi dillerini kullanır, ancak nadiren buna ihtiyacınız vardır). Açık kaynaklı, yaygın olarak kullanılan ve Apache lisanslıdır. Sorun ne olabilir?

DI çerçevesinin değiştirilmesinin büyüklük sıralarının diğer kütüphaneleri değiştirmekten daha kolay olacağından eminim (örneğin, bir UI değişikliği çok daha fazla iş anlamına gelir).