Son zamanlarda yoğun bir şekilde bağımlılık enjeksiyonunu yaptığımız bir Python projesi üzerinde çalıştım (çünkü uygulamanın test edilebilmesi için yapmalıyız), ancak herhangi bir çerçeve kullanmadık. Zaman zaman bütün bağımlılıkları elle bağlamak biraz sıkıcıydı, ama genel olarak harika çalıştı.

Bir nesnenin birden fazla yerde yaratılması gerektiğinde, bir üretim örneği oluşturmak için bir işlevimiz vardı (bazen o nesnenin bir sınıf yöntemi). Bu işleve ne zaman ihtiyacımız olursa çağrıldı.

Testlerde aynı şeyi yaptık: eğer bir kerede bir nesnenin 'test-versiyonunu' yaratmamız gerekiyorsa (yani, sahte nesneler tarafından desteklenen gerçek bir örnek), bu 'test-versiyonunu' yaratma fonksiyonumuz vardı. Testlerde kullanılmak üzere bir sınıf

Dediğim gibi, genellikle bu işe yaradı.

Şimdi yeni bir Java projesine giriyorum ve DI çerçevesinin kullanılıp kullanılmayacağına veya bir önceki projede olduğu gibi DI'nin manuel olarak mı kullanılacağına karar veriyoruz.

Lütfen bir DI çerçevesi ile çalışmanın ne kadar farklı olacağını ve manüel 'vanilya' bağımlılığı enjeksiyonundan ne şekilde daha iyi veya daha kötü olduğunu açıklayınız.

Düzenleme: Ayrıca soruyu da eklemek isterim: DI ile manuel olarak herhangi bir çerçeve olmadan herhangi bir “profesyonel seviye” projesine şahit oldunuz mu?

DI kapların anahtarı soyutlamadır . DI konteynerleri bu tasarım endişesini sizin için soyutlar. Tahmin edebileceğiniz gibi, kod üzerinde gözle görülür bir etkiye sahiptir, çoğunlukla daha az sayıda yapıcıya, ayarlayıcıya, fabrikaya ve inşaatçıya çevrilir. Sonuç olarak, kodunuzu daha gevşek bir şekilde birleştirir (altta yatan IoC nedeniyle ), daha temiz ve basittir. Her ne kadar hiçbir ücret ödemeden.

Arka

Yıllar önce, bu soyutlama çeşitli yapılandırma dosyalarını yazmamızı istedi ( bildirimsel programlama ). LOC sayısının önemli ölçüde azaldığını görmek harikaydı, ancak LOCS'ler azalırken, yapılandırma dosyalarının sayısı biraz arttı. Orta ve küçük projeler için hiç sorun olmadı, ancak daha büyük projeler için, kod ve XML tanımlayıcıları arasında% 50 dağınık “kodun derlenmesi” olması bir sıkıntı haline geldi… Yine de asıl sorun şuydu: paradigmanın kendisi. Tanımlayıcılar özelleştirmeler için çok az yer bıraktığı için oldukça esnekti.

Paradigma , ek açıklama veya nitelikler için yapılandırma dosyalarını alan, yapılandırma üzerinden konvansiyona doğru kaymıştır . XML'in yapamayacağı esnekliği sağlarken kodumuzu daha temiz ve daha basit tutar.

Muhtemelen, şu ana kadar nasıl çalıştığınızla ilgili en önemli fark budur. Daha az kod ve daha fazla sihir.

Aşağı tarafta ...

Yapılandırma üzerine yapılan sözleşme, soyutlamayı o kadar ağırlaştırır ki, nasıl çalıştığını çok az bilirsiniz. Bazen sihir görünür ve burada bir dezavantaj daha geliyor. Bir kere çalışıyor, birçok geliştirici nasıl çalıştığını umursamıyor.

Bu DI kapları ile DI öğrenenler için bir handikaptır. Tasarım kalıplarının uygunluğunu, iyi uygulamaları ve kabın soyutladığı ilkeleri tam olarak anlamıyorlar. Geliştiricilere DI ve avantajlarına aşina olup olmadıklarını sordum ve cevap verdiler: - Evet, Spring IoC'yi kullandım . (Bu ne anlama geliyor?!?)

Kişi bu "dezavantajların" her biriyle aynı fikirde olabilir veya olmayabilir. Benim düşünceme göre, projenizde neler olup bittiğini bilmek bir zorunluluktur. Aksi takdirde, tam olarak anlayamayız. Ayrıca DI'nin ne için olduğunu bilmek ve onu nasıl uygulayacağına dair bir fikre sahip olmak da dikkate alınması gereken bir artıdır.

Artı tarafta...

Tek kelime üretkenliği . Altyapı, gerçekten önemli olana odaklanmamızı sağlar. Uygulamanın işi.

Yorumlanan eksikliklere rağmen, çoğumuz için (hangi işi son teslim tarihlerine ve maliyetlere göre şartlandırılmış), bu araçlar paha biçilmez bir kaynaktır. Benim düşünceme göre, bu bir DI kaplarının uygulanması lehine ana argümanımız olmalıdır. Verimlilik .

Test yapmak

Saf DI veya kaplar uygularsak test yapmak sorun olmaz. Tam tersi. Aynı kaplar genellikle bize kutudan ünite testi için alaylar sağlar. Yıllar boyunca testlerimi termometre olarak kullandım. Konteyner tesislerine çok güvenip güvenmediğimi söylediler. Bunu söylüyorum, çünkü bu kapsayıcılar ayarlayıcılar ya da kurucular olmadan özel özellikleri başlatabilirler. Neredeyse her yere bileşenleri enjekte edebilirler!

Doğru cazip geliyor? Dikkatli ol! Tuzağa düşmeyin !!

Öneriler

Kapları uygulamaya karar verirseniz, iyi uygulamalara bağlı kalmanızı şiddetle tavsiye ederim. Yapıcıları, ayarlayıcıları ve arayüzleri uygulamaya devam edin. Kullanmak için çerçeveyi / kabı zorlayın . Başka bir çerçeveye geçişi mümkün kılacak veya asıl olanı kaldıracak. Kabı bağımlılığı önemli ölçüde azaltabilir.

Bu uygulamalar ile ilgili olarak:

• Bağımlılık Enjeksiyonu: Alan Enjeksiyonu vs Yapıcı Enjeksiyonu?

DI kapları ne zaman kullanılır?

Cevabım, çoğunlukla DI konteynerlerinin lehine olan kendi deneyimlerimden etkilenecek (yorumladığım gibi, yoğun bir şekilde üretkenliğe odaklanıyorum, bu yüzden hiçbir zaman saf DI'ye ihtiyacım olmadı).

Sanırım Mark Seeman'ın bu konuyla ilgili makalesini bulacağınızı düşünüyorum , bu da saf Dİ'nin nasıl uygulanacağıyla ilgili soruyu cevaplıyor .

Son olarak, eğer Java'dan bahsetmiş olsaydık , önce JSR330 - Bağımlılık Enjeksiyonuna bir göz atmayı düşünürdüm .

Özetleme

Faydaları :

• Maliyet düşürme ve zaman tasarrufu. Üretkenlik.
• Daha az sayıda bileşen.
• Kod daha basit ve daha temiz hale gelir.

Dezavantajları :

• DI, 3. parti lib'lerine devrediliyor. Takasları, güçlü yönleri ve zayıf yönlerinin farkında olmalıyız.
• Öğrenme eğrisi.
• Çabucak bazı alışkanlıkları unuttururlar.
• Projenin bağımlılıklarının artması (daha fazla lib)
• Yansıtmaya dayalı kaplar daha fazla kaynak gerektirir (bellek). Kaynaklar tarafından kısıtlanırsak bu önemlidir.

Saf DI ile farklılıklar :

• Daha az kod ve daha fazla yapılandırma dosyası veya ek açıklama.

Tecrübelerime göre, bağımlılık enjeksiyon çerçevesi bir dizi soruna yol açmaktadır. Sorunlardan bazıları çerçeveye ve araçlara bağlı olacaktır. Sorunları hafifleten uygulamalar olabilir. Ama bunlar benim çarptığım konular.

Global olmayan nesneler

Bazı durumlarda, global bir nesneyi enjekte etmek istersiniz: çalışan uygulamanızda yalnızca bir örneği olacak bir nesne. Bu olabilir MarkdownToHtmlRendererer, bir DatabaseConnectionPool, bağımlılık enjeksiyon çerçeveler çok sade bir şekilde çalışmak Bu gibi durumlar için vb API sunucu adresi, sadece yapıcı için gerekli bağımlılığı ekleyin ve bunu var.

Peki ya küresel olmayan nesneler? Şu anki istek için kullanıcıya ihtiyacınız varsa? Şu anda aktif veritabanı işlemine ihtiyacınız varsa? Ya henüz bir olay başlatan bir metin kutusunun bulunduğu bir form içeren div'e karşılık gelen HTML öğesine ihtiyacınız varsa?

DI çerçevelerinde kullandığım çözümü, hiyerarşik enjektörler oluşturuyor. Ancak bu enjeksiyon modelini daha karmaşık hale getirir. Hiyerarşinin hangi katmanından ne enjekte edileceğini bulmak zorlaşır. Belirli bir nesnenin uygulama başına, kullanıcı başına, istek başına vb. Var olup olmadığını söylemek zorlaşır. Artık sadece bağımlılıklarınızı ekleyemez ve çalışmasını sağlayamazsınız.

Kütüphaneler

Genellikle tekrar kullanılabilir bir kod kütüphanesine sahip olmak istersiniz. Bu, aynı zamanda bu koddan nesnelerin nasıl oluşturulacağına ilişkin talimatları da içerecektir. Bir bağımlılık enjeksiyon çerçevesi kullanıyorsanız, bu genellikle bağlayıcı kurallar içerecektir. Kütüphaneyi kullanmak istiyorsanız, bağlayıcı kurallarını kendinize ekleyin.

Ancak, çeşitli sorunlar ortaya çıkabilir. Farklı uygulamalara bağlı aynı sınıfa sahip olabilirsiniz. Kütüphane bazı bağların var olmasını bekleyebilir. Kitaplık, kodunuzun garip bir şey yapmasına neden olan bazı varsayılan bağlantıları geçersiz kılabilir. Kodunuz, kütüphane kodunun garip şeyler yapmasına neden olan bazı varsayılan bağlayıcıları geçersiz kılabilir.

Gizli Karmaşıklık

Fabrikaları manuel olarak yazdığınızda, uygulamanın bağımlılıklarının nasıl bir araya geldiğini anlıyorsunuz. Bağımlılık enjeksiyon çerçevesi kullandığınızda, bunu görmüyorsunuz. Bunun yerine, nesneler er ya da geç her şey hemen hemen her şeye bağlı olana kadar giderek daha fazla bağımlılık kazanma eğilimindedir.

IDE Desteği

IDE'niz muhtemelen bağımlılık enjeksiyon çerçevesini anlamıyor. Manuel fabrikalarda, nesnenin inşa edilebileceği tüm yerleri bulmak için yapıcının tüm arayanlarını bulabilirsiniz. Ancak DI çerçevesi tarafından oluşturulan çağrıları bulamaz.

Sonuç

Bağımlılık enjeksiyon çerçevesinden ne alıyoruz? Nesneleri somutlaştırmak için ihtiyaç duyulan basit fikirli bir kazandan kaçınıyoruz. Hepiniz basit fikirli kazan plakasını ortadan kaldırdığım için varım. Ancak, basit fikirli kazanı korumak kolaydır. Eğer bu kazan plakasını değiştireceksek, daha kolay bir şeyle değiştirmekte ısrar etmeliyiz. Yukarıda tartıştığım çeşitli meseleler nedeniyle, çerçevelerin (en azından oldukları gibi) tasarıya uygun olduğunu sanmıyorum.

Java + bağımlılık enjeksiyonu = çerçeve gerekli mi?

Yok hayır.

Bir DI çerçevesi beni ne satın alır?

Java olmayan bir dilde gerçekleşen nesne yapımı.

Eğer fabrika yöntemleri ihtiyaçlarınız için yeterliyse,% 100 otantik pojo java'da tamamen ücretsiz olarak Java'da DI yapabilirsiniz. İhtiyaçlarınız bunun ötesine geçerse, başka seçenekleriniz de vardır.

Dörtlü Tasarım desenleri Çetesi birçok harika şeyi başarır, ancak yaratılışsal modellere gelince her zaman zayıf yanları vardır. Java'nın burada bazı zayıf yönleri var. DI çerçeveleri gerçekten bu yaratıcı zayıflıklara, gerçek enjeksiyonlardan daha fazla yardımcı olmaktadır. Onlar olmadan nasıl yapılacağını zaten biliyorsun. Ne kadar iyi yapacakları, nesne inşası için ne kadar yardıma ihtiyacınız olduğuna bağlıdır.

Dörtlü Çeteden sonra ortaya çıkan birçok yaratılış örüntüleri var. Josh Bloch kurucusu, java'nın adlandırılmış parametreler eksikliği konusunda harika bir saldırıdır. Bunun ötesinde, çok fazla esneklik sunan iDSL üreticileri. Ancak bunların her biri, önemli çalışmaları ve kazanları temsil eder.

Altyapılar sizi bu tiranın bazılarından kurtarabilir. Dezavantajları yoktur. Dikkatli değilseniz, kendinizi çerçeveye bağlı olarak bulabilirsiniz. Birini kullandıktan sonra çerçeveleri değiştirmeyi deneyin ve kendiniz görün. Her ne kadar bir şekilde xml veya notları genel tutsanız bile, programlama işlerinin reklamını yaparken yan yana bahsetmeniz gereken iki dilin ne olduğunu desteklemeye başlayabilirsiniz.

DI çerçevelerinin gücüne fazla hayran kalmadan önce biraz zaman ayırın ve aksi takdirde bunun için bir DI çerçevesine ihtiyaç duyabileceğinizi düşünebileceğiniz yetenekleri veren diğer çerçeveleri araştırın. Birçoğu basit DI'nin ötesine dallandı . Şunu düşünün: Lombok , AspectJ ve slf4J . Her biri bazı DI çerçevelerle örtüşüyor, ancak her biri kendi başına iyi çalışıyor.

Eğer test gerçekten bunun arkasındaki itici güç ise, lütfen şunları göz önünde bulundurun: DI bir çerçevenin hayatınızı devralması gerektiğini düşünmeden önce jUnit ( gerçekten herhangi bir xUnit) ve Mockito (gerçekten herhangi bir alay) .

Ne istersen yapabilirsin, ama ciddi bir iş için iyi doldurulmuş bir alet kutusunu İsviçre çakısı için tercih ediyorum. Keşke bu çizgileri çizmek daha kolay olsa da, bazıları bulanıklaştırmak için çok çalıştılar. Bunda yanlış bir şey yok ama bu seçimleri zorlaştırabilir.

Sınıflar oluşturmak ve onlara bağımlılıklar atamak, modelleme sürecinin bir parçası, eğlenceli kısımlar. Programcıların çoğunun programlamayı sevmesinin nedeni budur.

Hangi uygulamanın kullanılacağına ve sınıfların nasıl oluşturulacağına karar vermek, bir şekilde uygulanması gereken ve uygulama yapılandırmasının bir parçası olan bir şeydir.

Fabrikaları elle yazmak sıkıcı bir iştir. DI çerçeveleri, çözülebilen bağımlılıkları otomatik olarak çözerek ve olmayanlar için konfigürasyon gerektiren işleri kolaylaştırır.

Modern IDE'leri kullanmak, yöntemler ve kullanımları arasında gezinmenizi sağlar. Elle yazılmış fabrikalara sahip olmak oldukça iyidir, çünkü bir sınıfın kurucusunu vurgulayabilir, kullanımlarını gösterebilir ve belirli bir sınıfın nerede ve nasıl oluşturulduğunu size gösterecektir.

Ancak DI çerçevesiyle bile, nesne grafiği yapı yapılandırması (bundan böyle OGCC) gibi merkezi bir yeriniz olabilir ve bir sınıf belirsiz bağımlılıklara bağlıysa, basitçe OGCC'ye bakabilir ve belirli bir sınıfın nasıl oluşturulduğunu görebilirsiniz tam orada.

Kişisel olarak, belirli bir kurucunun kullanımlarını görebilmenin büyük bir artı olduğunu düşünmenize itiraz edebilirsiniz. Size daha iyi çıkan şeylerin yalnızca öznel değil, çoğunlukla kişisel deneyimlerden kaynaklandığını söyleyebilirim.

Her zaman DI çerçevelerine dayanan projeler üzerinde çalışmış olsaydınız, gerçekten bunu biliyordunuz ve bir sınıfın konfigürasyonunu görmek istediğinizde, her zaman OGCC'ye bakardınız ve hatta kurucuların nasıl kullanıldığını görmeyi denemezdiniz. Çünkü, bağımlılıkların yine de otomatik olarak bağlandığını biliyordunuz.

Doğal olarak, DI çerçeveleri her şey ve her şey için kullanılamaz ve daha sonra bir veya iki fabrika metodu yazmanız gerekecektir. Çok yaygın bir durum, her bir yinelemenin başka bir ortak arabirimin farklı bir uygulamasını üretmesi gereken farklı bir bayrak sağladığı bir koleksiyon üzerinde yineleme sırasında bir bağımlılık oluşturmaktır.

Sonunda, tercihlerinizin ne olduğuna ve ne feda etmeye istekli olduğunuza (fabrikalar yazarken veya şeffaflıkta) büyük olasılıkla hepsi ortaya çıkacaktır.

Kişisel deneyim (uyarı: öznel)

Bir PHP geliştiricisi olarak konuşurken, DI çerçevelerinin arkasındaki fikri sevmeme rağmen, onları yalnızca bir kez kullandım. Çalıştığım bir ekibin bir uygulamayı çok hızlı bir şekilde kullanması gerekiyordu ve fabrika yazma zamanını kaybedemedik. Biz sadece bir DI çerçeve aldı Yani, yapılandırır ve o amele nasılsa .

Çoğu proje için fabrikaları el ile yazmayı seviyorum, çünkü DI çerçevelerindeki kara büyüyü sevmiyorum. Bir sınıfı ve bağımlılıklarını modellemekten sorumlu kişi bendim. Tasarımın neden göründüğü gibi göründüğüne karar veren bendim. Bu yüzden sınıfı düzgün bir şekilde oluşturan kişi olacağım (sınıf, arayüzler yerine somut sınıflar gibi zor bağımlılıklar olsa bile).

Şahsen ben DI-konteyner kullanmıyorum ve onlardan hoşlanmıyorum. Bunun için birkaç nedenim daha var.

Genellikle statik bir bağımlılıktır. Bu yüzden tüm dezavantajları ile sadece bir servis bulucu . Sonra, statik bağımlılıkların doğası gereği, gizlenirler. Onlarla uğraşmanıza gerek yok, onlar zaten bir şekilde oradalar ve tehlikeli, çünkü onları kontrol etmeyi bırakıyorsunuz.

Bu OOP ilkelerinin kırar böyle uyum ve gibi David West 'in Lego tuğla nesne metafor.

Bu nedenle, tüm nesneyi programın giriş noktasına mümkün olduğunca yakın oluşturmak , yolunu çizmektir.

Daha önce fark ettiğiniz gibi: Kullandığınız dile bağlı olarak, farklı bakış açıları var, farklı olanlar benzer sorunlarla nasıl başa çıkacaklarını düşünüyor.

Bağımlılık enjeksiyon ile ilgili olarak, bu aşağı gelir: vadeli söylediği gibi bağımlılık enjeksiyon fazla, başka bir şey değildir bağımlılıkları bir nesne ihtiyaçlarını koyarak içine bu nesne - başka bir yol zıt: kendisi nesnelerin örneklerini instatiate nesneyi icar o bağlıdır. Daha fazla esnekliğin kazanılması için nesne oluşturma ve nesne tüketimini ayrıştırıyorsunuz .

Tasarımınız iyi düzenlenmişse, genellikle birçok bağımlılığa sahip birkaç sınıfa sahipsiniz, bu nedenle bağımlılıkları kablolama - elle ya da bir çerçeveyle - nispeten kolay olmalı ve testleri yazmak için kazan plakası miktarı kolay yönetilebilir olmalıdır.

Bununla birlikte, DI-çerçevesine gerek yoktur.

Fakat neden yine de bir çerçeve kullanmak istiyorsun?

I) Kazan kodunu kullanmaktan kaçının

Projeniz bir büyüklük kazanırsa, fabrikaları (ve instatiations'ları) tekrar tekrar yazmanın acısını hissederseniz, bir DI-framework kullanmalısınız.

II) Programlamaya declacrative yaklaşım

Java bir zamanlar XML ile programlama yaparken , şimdi: şerbetçiotuyla adil bir şekilde serpme ve sihir gerçekleşir .

Ama ciddi: Ben net bir bakın ters Buna. Neyi nerede bulacağınız ve neyi nasıl inşa edeceğimiz yerine neye ihtiyaç duyduğunuzu söyleme niyetiyle açıkça iletişim kurarsınız.

tl; Dr.

DI çerçeveleri, kod tabanınızı sihirli bir şekilde daha iyi hale getirmez, ancak iyi görünen kodun gerçekten net görünmesini sağlar . İhtiyacınız olduğunu hissettiğiniz zaman kullanın. Projenizin belirli bir noktasında, size zaman kazandıracak ve mide bulantısını önleyecektir.

Evet. Muhtemelen Mark Seemann'ın "Bağımlılık Enjeksiyonu" adlı kitabını okumalısınız. Bazı iyi uygulamaların ana hatlarını çiziyor. Söylediklerinize dayanarak, bundan faydalanabilirsiniz. İş birimi başına bir kompozisyon kökü veya bir kompozisyon kökü olmasını hedeflemelisiniz (örneğin, web isteği). Yarattığınız herhangi bir nesnenin bir bağımlılık olarak kabul edildiğini düşünme yönteminden hoşlanırım (bir yöntem / kurucu için herhangi bir parametre olduğu gibi), bu nedenle nesnelerin nerede ve nasıl oluşturulduğuna gerçekten dikkat etmeniz gerekir. Bir çerçeve bu kavramları açık tutmanıza yardımcı olacaktır. Mark'ın kitabını okursanız, sadece sorunuzun cevabından daha fazlasını bulacaksınız.

Evet, Java'da çalışırken, DI çerçevesini öneririm. Bunun birkaç nedeni var:

• Java, otomatik bağımlılık enjeksiyonu sunan birçok son derece iyi DI paketine sahiptir ve genellikle basit DI'den daha el ile yazması daha zor olan ek yeteneklerle de paketlenmiştir (örneğin, kapsamlar arasında hangi kapsamda olması gerektiğine bakmak için kod üreterek kapsamlar arasında otomatik bağlantı sağlayan otomatik bağımlılıklar) Bu kapsam için bağımlılığın doğru versiyonunu bulmak için bir d kullanın. Örneğin uygulama kapsamındaki nesneler kapsam kapsamındakileri talep edebilir.

• Java ek açıklamaları son derece kullanışlıdır ve bağımlılıkları yapılandırmanın mükemmel bir yolunu sağlar.

• java nesnesi yapısı python'da alıştığınıza kıyasla aşırı derecede ayrıntılı; Burada bir çerçeve kullanmak, dinamik bir dilde olduğundan daha fazla iş tasarrufu sağlar.

• java DI çerçeveleri Java'da dinamik bir dilden çok daha fazla işe yarayan otomatik olarak proxy oluşturma ve dekoratör oluşturma gibi faydalı şeyler yapabilir.

Projeniz yeterince küçükse ve DI-Framework ile ilgili çok fazla tecrübeniz yoksa , çerçeveyi kullanmamanızı ve manuel olarak yapmanızı öneririm .

Sebep: Bir keresinde, farklı çerçevelere doğrudan bağımlılıkları olan iki kütüphaneyi kullanan bir projede çalıştım. Her ikisinde de, XYZ'nin bir örnek ver-di-bana-ver gibi çerçeve kodları vardı. Bildiğim kadarıyla bir seferde sadece bir aktif di-framework uygulamasına sahip olabilirsiniz.

Bunun gibi bir kodla faydadan daha çok zarar verebilirsiniz.

Daha fazla deneyime sahipseniz, muhtemelen bir çerçeveyle di-çerçeveyi soyutlarsınız (fabrika veya servis görevlisi), bu nedenle bu sorun daha fazla olmayacak ve di çerçevesi zarar vermekten daha fazla fayda sağlayacaktır.