Bağımlılık enjeksiyonu için neden çerçevelere ihtiyacımız var? [kapalı]


42

Bunun bir uygulaması olarak Kontrolün Tersine Çevirilmesi prensibi ve Bağımlılık Enjeksiyonu hakkında daha fazla şey okudum ve anladığımdan eminim.

Temel olarak 'sınıf üyelerinizi' sınıf içindeki örneklemeler ilan etme 'diyor gibi görünüyor. Aksine, örneklemeler kurucu aracılığıyla yerine getirilmeli ve atanmalıdır; Dış bir kaynaktan sınıfa 'enjekte edilir'.

Bu kadar basitse, göründüğü gibi, neden bunu ek açıklamalarla uygulayan bahar ya da guice gibi çerçevelere ihtiyacımız var? Burada temel bir şeyi mi özlüyorum? Bağımlılık Enjeksiyonu çerçevelerinin kullanımının ne olduğunu anlamak için gerçekten mücadele ediyorum.

Düzenleme: Olası kopya hakkında, sadece Bahar değil, genel olarak DI çerçeveleri hakkında sorduğum gibi sorumun daha benzersiz olduğuna inanıyorum. Bahar sadece bir DI çerçevesi değildir, bu nedenle birinin DI ile ilgili olmayan Bahar'ı kullanmak istemesinin birçok nedeni vardır.



11
Hataları derleme zamanı yerine çalışma zamanına kaydırmak için kullanışlıdır.
Den

1
@den Neden bunu yapmak istiyoruz? Bu hızlı başarısız başarısız ihlal gibi görünüyor
BU KULLANICI

Yanıtlar:


26

Çerçevelere ihtiyacımız yok. Bağımlılık enjeksiyonunu, nispeten büyük bir projede bile manuel olarak uygulamak tamamen mümkündür.

Öte yandan, bir çerçeveyi kullanmak daha kolay, özellikle de açıklamalara veya bağımlılıkların otomatik olarak algılanmasına dayalı olarak, süreci daha kolay hale getirdiği için kolaylaştırır: bir sınıfta yeni bir bağımlılığa ihtiyacım olduğuna karar verirsem, yapmam gereken tek şey eklemek. yapıcıya (veya bir pasif ilan eder) ve nesneye enjekte edilir - Herhangi bir başlatma kodunu değiştirmem gerekmez.

Ayrıca, çerçeveler genellikle başka kullanışlı işlevler içerir. Örneğin bahar, bildirimsel işlem sınırlaması (son derece kullanışlı olan) ve birçok 3. parti kütüphanenin entegrasyonunu kolaylaştıran çeşitli adaptör uygulamaları da dahil olmak üzere en boy odaklı programlama için kullanışlı bir çerçeve içerir.


8
Taşı gediğine oturtmak. Biz yok onlara ihtiyacımız var. Sadece büyük projeler için hayatı kolaylaştırıyor. Dürüst olmak gerekirse, çerçevelerin daha küçük projeler için değeceklerinden daha fazla güçlük çektiğini görüyorum. OP'yi Bağımlılık Enjeksiyonunu onu destekleyen çerçevelerle karıştırmamaya teşvik ediyorum.
RubberDuck

1
iyi dedi. Ve neden başkası daha güzel ve yuvarlak bir tane yaptığında çarkı yeniden icat etti?
saat

Tam olarak. Dışında herhangi örnekleme kodunu değiştirmek gerekmez - tabii ki, hiçbir instantiation kodu yoktur ;-)
Mathieu Guindon

DI kütüphanelerinizin emdiği gibi görünüyor. İyi olanlar sınıfın yansıma kullanarak harekete geçeceğini tahmin edebilir.
Florian Margaine

2
Çalışma zamanı işleme için yansıma kullanan herkes yanlış yapıyor. Yansıtma, teknolojiden biridir, sadece bir şeyi yapabilmeniz gerektiği anlamına gelmez.
gbjbaanb

12
  1. Neden DI'ye (Bağımlılık Enjeksiyonu) ihtiyacımız var?

    DI mekanizması nesne üretimini nesne tüketiminden ayırır. Bir nesnenin ihtiyaç duyduğu bağımlılıklar şeffaf bir şekilde dışarıdan iletilir. Mekanizmanın avantajı açıktır: İstediğiniz zaman bağımlılıkları ortadan kaldırabilirsiniz, örneğin test amacıyla bir Null Object kullanmak.

  2. Nasıl oldu?

    Hedefe ulaşmak için çeşitli yollar vardır:

    • Yapıcı enjeksiyon yoluyla bağımlılıkları enjekte etme
    • Alıcı / ayarlayıcı ile enjeksiyon
    • Arayüz Enjeksiyonu
  3. DI çerçevelerine ihtiyacımız var mı?

    Hayır, hiç de değil. Tüm örnekleri manuel olarak başka nesnelere iletebilirsiniz. Küçük bir uygulamanız varsa, yaylı bir konteynere gerek yoktur.

    Ancak diğer yandan, çerçeveler nesneleri yöneterek size yardımcı bir el verir:

    • Karmaşık nesne ilişkilerini kablolamanıza yardımcı olurlar. Örnek üretmek ve bunları uygun nesnelere iletmek için bir boyler kodu yazmanız gerekmez.

    • Bir nesnenin ne zaman oluşturulduğunu kontrol etmenize yardımcı olurlar : uygulama önyüklemesi sırasında örnekler oluşturabilirsiniz, ancak bazı durumlarda tembel bir oluşturma - yalnızca gerektiğinde - daha iyidir

    • Kaç tane örnek oluşturulduğunu kontrol etmenize yardımcı olur : uygulama ömrü boyunca bir tane veya istek başına bir tane (web programlama yapıyorsanız)

Projeniz uygun bir boyuta sahipse - daha az kazan kodunu yazmanız gerektiğine inanıyorsanız - bir (DI-) çerçevesi kullanarak mantıklı geliyor. Eksilerden daha fazla avantaj var.


2
DI kütüphanelerini herhangi bir çerçeve kullanmadan kullanabilirsiniz.
Florian Margaine

5

İlkbaharda, çoğunlukla kolaylık meselesidir.

Sınıfı TopLeveloluşturan sınıfı MiddleLeveloluşturan sınıfınız LowLevelvarsa ve üzerinde yeni bir yapıcı parametresine ihtiyacınız olduğunu anlarsanız LowLevel, bunu da eklemeniz gerekir TopLevel, ve MiddleLevelbasitçe MiddleLevelbir LowLeveldeğer oluşturma zamanı geldiğinde kullanılabilir Böylece yapıcısına geçirilebilir. İlkbaharda, sadece bir açıklama ekleyin.

Ayrıca, yay ile, bağımlılıkları xml yerine harici bir yapılandırma dosyasında tanımlamak mümkündür ve bu size sözde "herhangi bir kod değiştirmeden" tamamen farklı bir kablolama ile yeni bir sistem oluşturma imkanı verir. (IMHO bu tamamen yanlış yönlendirilmiştir, çünkü xml'yi değiştirmek, kodu değiştirmekten çok farklı değildir ve aslında, kod genellikle xml'den çok daha iyi hata denetimi ve tür denetimi yapar.)

Başka bir şey, birçok insanın inşaatçılardan korkmasıdır; Onları anlamıyorlar, onlardan hoşlanmıyorlar, kullanmamayı tercih ediyorlar.


3
Çoğunlukla, özellikle de XML uyarısı ile aynı fikirde. IMHO, inşaatçılardan korkmak, DI çerçevesini kullanmak için muhtemelen kötü bir sebep.
Robert Harvey,

2
IMHO, kuruculardan korkmak programlamadan uzak durmak için iyi bir nedendir. C -: =
Mike Nakis

5
Fakat bunun bir fabrikaya göre avantajı nedir (statik veya başka türlü)? (Hangisi uygunsa kullanabileceğiniz bir seçenek olma avantajına sahiptir, oysa bahar haksızlıktan başka bir şey çıkmaz)
Richard Tingle

@ RichardTingle Spring, DI dışında kalan diğer tüm şeylerden dolayı çoğunlukla bir avantaj sağlayabilir, çünkü açıkça görülebilir ki, DI'yi diğer yollarla elde edebilirsiniz, statik fabrikalar birdir. (En havalı olanlardan biri, ama yine de.) Ancak soru, DI elde etmek için yay kullanmanın gerekli olup olmadığını soruyor. Cevap vermeye çalıştığım şey de buydu: temel olarak, gerekli değil, sadece bir kolaylık .
Mike Nakis

Bu, DI olmayanın bir örneğidir. “TopLevel” oluşturmamalı MiddleLevel, yapıcıya TopLevelbir argüman olarak oluştururken almalıdır . Aynı şekilde yapıcı MiddleLevelbir almalıdır LowLevel.
Daha temiz

1

Birkaç yıl önce, çalıştığım bir şirkette web sayfalarını, web portletlerini ve hatta bazı veritabanı tablolarını izlemek için bir program yazdım. Kullanıcının, hangi monitörlerin çalışacağını ve hangi parametrelerle (URL'ler, girişler, başarı kriterleri, vb.) Çalışabileceğini belirtebilmesi için esnek olmasını istedim. Bu yüzden bir XML dosyasından okumak ve belirtilen sınıfları başlatmak için Java yansımasını kullanmak ve belirtilen parametreleri ayarlamak için setter yöntemlerini kullanmak için yazdım.

Daha sonra Spring'in sizin için aynı şeyi yapacağını ve çok daha fazlasını yapacağımı öğrendim.

Yani benim durumumda bunu buldum

  1. Bağımlılık enjeksiyon çerçevesi kullanmak programın esnek olmasına yardımcı olur ve nasıl çalışacağını belirlemeyi kolaylaştırır (elbette iyi tanımlanmış parametreler dahilinde).

  2. Üçüncü taraf DI çerçevesini kullanmak, tekerleği yeniden icat etmenize engel olur.


4
Hangi somut sınıfın kullanılacağını neden bir java dosyası içinde değil de xml içinde daha iyi olduğunu açıklayabilir misiniz? Asla anlamadığım şey bu.
Richard Tingle

1
Sihirli mermi değildir, ancak config dosyalarını kullanmanın bir avantajı, en azından teoride, kodlardan daha kolay düzenlemeleridir. Ayrıca, programınızı çalıştıran ancak kaynak kodunuza erişmeyen bir kullanıcı tarafından değiştirilebilirler. Ham bağımlılık enjeksiyon programımdan bahsettiğim örnekte, bazen XML yapılandırma dosyasını değiştirirdim, böylece programı yazan kişi ben olsam da programın çalışma şeklini değiştirebilirdim. Harici yapılandırılabilirliğe ihtiyacınız yoksa, kodla yapmak daha kolay olabilir. Koddaki tüm DI'yi yaptığımız ve işe yarayan başka bir işim vardı.
Paul J Abernathy
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.