Bağımlılık Enjeksiyonu ve Servis Bulucu modelleri arasındaki fark nedir?


304

Her iki örüntü de kontrolün ters çevrilmesi ilkesinin bir uygulaması gibi görünmektedir. Yani, bir nesne bağımlılıklarını nasıl oluşturacağını bilmemelidir.

Bağımlılık Enjeksiyonu (DI) bağımlılıkları "enjekte etmek" için bir yapıcı veya ayarlayıcı kullanıyor gibi görünmektedir.

Yapıcı Enjeksiyonu kullanma örneği:

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

Servis Bulucu, bağımlılıklarını bağlayan ve ona bar veren bir "kap" kullanıyor gibi görünüyor.

Servis Bulucu kullanımına örnek:

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo()
  {
    this.bar = Container.Get<IBar>();
  }

  //...
}

Bağımlılıklarımız sadece nesnelerin kendileri olduğundan, bu bağımlılıkların, daha da fazla bağımlılığa sahip olan bağımlılıkları vardır, vb. Böylece, Kontrol Kapsayıcısının (veya DI Kapsayıcısının Tersi) doğmuştur. Örnekler: Windsor Kalesi, Ninject, Yapı Haritası, Bahar vb.)

Ancak bir IOC / DI Kapsayıcısı tam olarak bir Hizmet Bulucuya benziyor . Buna DI Konteyner kötü bir isim mi diyor? IOC / DI Kapsayıcısı başka bir tür Servis Bulucu mu? Nüans DI Konteynerleri daha çok Bağımlılığımız olduğunda kullanıyor mudur?


13
Kontrolün ters çevrilmesi, "bir nesnenin bağımlılıklarını nasıl oluşturacağını bilmemesi gerektiği" anlamına gelir. Bu benim için yeni. Hayır, gerçekten, "kontrolün ters çevrilmesi" demek değildir. Bkz. Martinfowler.com/bliki/InversionOfControl.html Bu makale 1980'lere dayanan terimin etimolojisi için bile referanslar sunmaktadır.
Rogério


1
Mark Seemann, Servis Konumlandırıcı'yı anti-desen olarak savunuyor ( blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern ). Ayrıca, diyagramı (burada bulunan stackoverflow.com/a/9503612/1977871 ) DI ve SL tahminini anlamak için yararlı buldum . Bu yardımcı olur umarım.
VivekDev

Yanıtlar:


181

Fark hafif görünebilir, ancak ServiceLocator ile bile, sınıf hala bağımlılıklarını oluşturmaktan sorumludur. Bunu yapmak için sadece servis bulucuyu kullanır. DI ile sınıfa bağımlılıkları verilir. Nereden geldiklerini bilmiyor ya da umursamıyor. Bunun önemli bir sonucu, DI örneğinin test edilmesinin çok daha kolay olmasıdır - çünkü bağımlı nesnelerinin sahte uygulamalarını iletebilirsiniz. İkisini birleştirebilir ve isterseniz servis bulucuyu (veya bir fabrikayı) enjekte edebilirsiniz.


20
Ayrıca, bir sınıf oluştururken her ikisini de kullanabilirsiniz. Varsayılan yapıcı, bağımlılıkları almak için SL'yi kullanabilir ve bu bağımlılıkları alan "gerçek" yapıcıya iletebilir. Her iki dünyanın da en iyisini elde edersiniz.
Grant Palin

6
Hayır, ServiceLocator, belirli bir bağımlılık (eklenti) için doğru uygulamayı somutlaştırmaktan sorumludur. DI durumunda, DI "konteyneri" bundan sorumludur.
Rogério

5
@Rogerio evet ama sınıf hala Servis Bulucu hakkında bilmek zorunda ... bu iki bağımlılık. Ayrıca sık sık Servis Bulucu özellikle servis desteğine ihtiyaç geçici nesneler aramak için DI konteyner delege gördüm.
Adam Gent

2
@Adam Servis Bulucu'nun bir DI konteynerine delege edeceğini söylemedim. Bunlar, "resmi" makalede açıklandığı gibi, birbirini dışlayan iki kalıptır . Bana göre, Servis Bulucu pratikte DI'ye karşı büyük bir avantaja sahiptir: Bir DI konteynerinin kullanılması, bir Servis Bulucu'nun kullanılmasına izin vermezken (tekrar tekrar gördüğüm) kötüye kullanımı davet eder.
Rogério

3
"Bunun önemli bir sonucu, DI örneğinin test edilmesinin çok daha kolay olmasıdır - çünkü bağımlı nesnelerinin sahte uygulamalarını iletebilirsiniz." Doğru değil. Birim testlerinizde, kayıt defterine kolayca alay eklemek için servis bulucu kapsayıcısındaki bir kayıt işlevine çağrı kullanılabilir.
Drumbeg

93

Bir servis bulucu kullandığınızda, her sınıf servis bulucuya bağımlı olacaktır. Bağımlılık enjeksiyonunda durum böyle değildir. Bağımlılık enjektörü, bazı ana sınıfa bağımlılıkları enjekte etmek için başlangıçta yalnızca bir kez çağrılacaktır. Bu ana sınıfın bağlı olduğu sınıflar, tam bir nesne grafiğine sahip oluncaya kadar bağımlılıkları tekrarlı olarak enjekte edilir.

İyi bir karşılaştırma: http://martinfowler.com/articles/injection.html

Bağımlılık enjektörünüz, sınıfların doğrudan enjektörü çağırdığı bir servis bulucuya benziyorsa, muhtemelen bir bağımlılık enjektörü değil, bir servis bulucudur.


17
Ancak çalışma zamanı sırasında nesne oluşturmanız gereken durumu nasıl ele alırsınız? Bunları "yeni" ile manuel olarak oluşturursanız DI'den yararlanamazsınız. Yardım için DI çerçevesini çağırırsanız, kalıbı kırarsınız. Peki hangi seçenekler kaldı?
Boris

9
@Boris Aynı problemi yaşadım ve sınıfa özel fabrikalar enjekte etmeye karar verdim. Güzel değil ama işi bitirdi. Daha güzel bir çözüm görmek isterim.
Charlie Rudenstål

Karşılaştırma için doğrudan bağlantı: martinfowler.com/articles/…
Teoman shipahi

2
@Boris Anında yeni nesneler inşa etmem gerekirse, söz konusu nesneler için bir Soyut Fabrika enjekte ederim. Bu, bu durumda bir servis bulucu enjekte etmeye benzer, ancak ilgili nesneleri oluşturmak için somut, tekdüze, derleme zamanı, bir arayüz sağlar ve bağımlılıkları açık hale getirir.
LivePastTheEnd

51

Hizmet konum belirleyicileri bağımlılıkları gizler - bir nesneye veritabanına isabet edip etmediğini (örneğin, bir konumlandırıcıdan bağlantı elde ettiğinde) söyleyemezsiniz. Bağımlılık enjeksiyonu ile (en azından yapıcı enjeksiyonu) bağımlılıklar açıktır.

Ayrıca, hizmet konumlandırıcıları, diğer nesnelerin bağımlılıklarına küresel bir erişim noktası sağladıkları için kapsüllemeyi keser. Herhangi bir singletonda olduğu gibi servis bulucu ile :

uygulama nesnesinin arabirimi için ön ve son koşullarını belirtmek zorlaşır, çünkü uygulamasının çalışmaları dışarıdan karıştırılabilir.

Bağımlılık enjeksiyonu ile, bir nesnenin bağımlılıkları belirtildikten sonra, nesnenin kendisinin kontrolü altındadır.



2
Steve Yegge'yi seviyorum ve bu makalenin başlığı harika, ama alıntıladığım makale ve Miško Hevery'nin "Singletons Patolojik yalancılar" ( misko.hevery.com/2008/08/17/singletons-are-pathological- yalancı ) servis bulucu özel şeytanlık karşı daha iyi bir dava yapmak.
Jeff Sternal

Bu cevap en doğru olanıdır çünkü bir servis bulucuyu en iyi tanımlar: "Bağımlılıklarını gizleyen bir sınıf." Dahili olarak bir bağımlılık oluşturmanın, çoğu zaman iyi bir şey olmasa da, bir sınıfı bir servis bulucu yapmadığını unutmayın. Ayrıca, bir kapsayıcıya bağımlı olmak bir problemdir, ancak bir servis bulucuyu en açık şekilde tanımlayan "" "problemi değildir.
Sam

1
With dependency injection (at least constructor injection) the dependencies are explicit.. Lütfen açıkla.
FindOutIslamNow

Yukarıdaki gibi, SL'nin bağımlılıkların
DI'den

38

Martin Fowler şunları söylüyor :

Hizmet konumlandırıcı ile uygulama sınıfı, konumlayıcıya bir mesajla açıkça ister. Enjeksiyonla açık bir istek yoktur, hizmet uygulama sınıfında görünür - dolayısıyla kontrolün ters çevrilmesi.

Kısacası: Servis Bulucu ve Bağımlılık Enjeksiyonu sadece Bağımlılık Ters Çevirme Prensibinin uygulamalarıdır.

Önemli ilke “Sözleşmelere değil, Soyutlamalara Bağlı” dır. Bu, yazılım tasarımınızı “gevşek bağlı”, “genişletilebilir”, “esnek” hale getirecektir.

İhtiyaçlarınıza en uygun olanı kullanabilirsiniz. Büyük bir uygulama için, büyük bir kod tabanına sahip olmak için, bir Servis Bulucu kullanmanız daha iyi olur, çünkü Bağımlılık Enjeksiyonu kod tabanınızda daha fazla değişiklik gerektirir.

Bu gönderiyi kontrol edebilirsiniz: Bağımlılık Ters Çevirme: Servis Bulucu veya Bağımlılık Enjeksiyonu

Ayrıca klasik: Kontrol Kaplarının Ters Çevirilmesi ve Bağımlılık Enjeksiyonu kalıbı Martin Fowler

Yeniden Kullanılabilir Sınıflar Tasarlamak - Ralph E. Johnson & Brian Foote

Ancak, gözlerimi açan: ASP.NET MVC: Çöz veya Enjekte Et? Sorun… Dino Esposito tarafından


Fantastik özeti: "Servis Bulucu ve Bağımlılık Enjeksiyonu sadece Bağımlılık İnversiyon Prensibi uygulamalarıdır."
Hans

Ve ayrıca şunu belirtiyor: Temel fark, bir Servis Bulucu ile bir servisin her kullanıcısının konumlandırıcıya bağımlı olmasıdır. Konumlandırıcı diğer uygulamalara bağımlılıkları gizleyebilir, ancak konumlayıcıyı görmeniz gerekir. Dolayısıyla, konumlandırıcı ve enjektör arasındaki karar, bu bağımlılığın bir sorun olup olmadığına bağlıdır.
programaths

1
ServiceLocator ve DI'nin "Bağımlılık Ters Çevirme İlkesi" (DIP) ile hiçbir ilgisi yoktur. DIP, düşük seviyeli bir bileşene derleme zamanı bağımlılığını, düşük seviyeli bileşen tarafından uygulanan yüksek seviyeli bileşenle birlikte tanımlanmış soyut bir türe bağımlı bir şekilde değiştirerek, yüksek seviyeli bir bileşeni daha yeniden kullanılabilir hale getirmenin bir yoludur. seviye bileşeni; bu şekilde derleme zamanı bağımlılığı tersine çevrilir, çünkü şimdi üst düzey olana bağlı olan düşük düzeyli bağımlılıktır. Ayrıca Martin Fowler'in makalesinde DI ve IoC'nin aynı şey olmadığını açıkladığını unutmayın .
Rogério

23

Yapıcı DI kullanan bir sınıf, tüketilmesi gereken bağımlılıkların olduğu kodun tüketildiğini gösterir. Sınıf bu tür bağımlılıkları almak için SL'yi dahili olarak kullanıyorsa, tüketen kod bağımlılıkların farkında değildir. Bu yüzeyde daha iyi görünebilir, ancak açık bağımlılıkları bilmek gerçekten yararlıdır. Mimari açıdan daha iyidir. Ve test yaparken, bir sınıfın belirli bağımlılıklara ihtiyaç duyup duymadığını bilmeniz ve SL'yi bu bağımlılıkların uygun sahte sürümlerini sağlayacak şekilde yapılandırmanız gerekir. DI ile sadece sahte olanları geçirin. Büyük bir fark değil, ama orada.

Yine de DI ve SL birlikte çalışabilir. Yaygın bağımlılıklar için merkezi bir konuma sahip olmak yararlıdır (örn. Ayarlar, kaydedici, vb.). Bu tür depsleri kullanan bir sınıf verildiğinde, depleri alan bir "gerçek" yapıcı ve SL'den alıp "gerçek" yapıcıya ileten varsayılan (parametre yok) bir yapıcı oluşturabilirsiniz.

DÜZENLEME: ve elbette, SL'yi kullandığınızda, bu bileşene bir miktar bağlantı getireceksiniz. Bu ironiktir, çünkü böyle bir işlevsellik fikri soyutlamaları teşvik etmek ve eşleşmeyi azaltmaktır. Endişeler dengelenebilir ve SL'yi kaç yerde kullanmanız gerektiğine bağlıdır. Yukarıda önerildiği gibi yapılırsa, sadece varsayılan sınıf yapıcısında.


İlginç! Hem DI hem de SL kullanıyorum, ancak iki kurucu ile kullanmıyorum. Sıklıkla ihtiyaç duyulan üç veya dört sıklıkta ihtiyaç duyulan bağımlılıklar (ayarlar, vb.) SL'den anında elde edilir. Diğer her şey yapıcı enjekte edilir. Biraz çirkin ama pragmatik.
maaartinus

10

Her ikisi de IoC'nin uygulama teknikleridir. Kontrolün İnversiyonunu uygulayan başka desenler de vardır:

  • Fabrika desen
  • Servis bulucu
  • DI (IoC) Konteyneri
  • Bağımlılık enjeksiyonu (yapıcı enjeksiyonu, parametre enjeksiyonu (gerekli değilse), arayüz enjeksiyonunun ayarlayıcı enjeksiyonu) ...

Servis bulucu ve DI Konteyner daha benzer görünüyor, her ikisi de bağımlılığı tanımlamak için bir kap kullanıyor ve bu da soyutlamayı somut uygulamaya eşliyor.

Temel fark, bağımlılıkların nasıl bulunduğudur, Servis Bulucu'da istemci kodu bağımlılıkları ister, DI Container'da tüm nesneleri oluşturmak için bir kap kullanırız ve yapıcı parametreleri (veya özellikleri) olarak bağımlılığı enjekte eder.


7

Son projemde her ikisini de kullanıyorum. Ünite test edilebilirliği için bağımlılık enjeksiyonu kullanıyorum. Uygulamayı gizlemek ve IoC kapsayıcıma bağımlı olmak için servis bulucu kullanıyorum. ve evet! IoC kaplarından birini (Unity, Ninject, Windsor Kalesi) kullandığınızda buna güvenirsiniz. Ve bir kez modası geçtikten sonra veya herhangi bir nedenle takas etmek isteyecekseniz, en azından kompozisyon kökü olmak üzere uygulamanızı değiştirmeniz gerekebilir / gerekebilir. Ancak servis bulucu bu aşamayı soyutlar.

IoC konteynırınıza nasıl güvenmezsiniz? Ya kendiniz sarmanız gerekir (bu kötü bir fikirdir) veya IoC kabınızı yapılandırmak için Servis Bulucu'yu kullanırsınız. Böylece servis bulucuya hangi arabirime ihtiyacınız olduğunu söyleyeceksiniz ve bu arabirimi almak için yapılandırılmış IoC kapsayıcısını çağırır.

Benim durumumda, bir çerçeve bileşeni olan ServiceLocator kullanıyorum . Ve kullanmak Unity IoC kapsayıcı için. İleride IoC konteyneri Ninject ile değiştirmem gerekiyorsa, tüm yapmam gereken Servis bulucumu Unity yerine Ninject kullanacak şekilde yapılandırmam gerekiyor. Kolay taşıma.

İşte bu senaryoyu açıklayan harika bir makale; http://www.johandekoning.nl/index.php/2013/03/03/dont-wrap-your-ioc-container/


Johandekoning makale bağlantısı bozuk.
JakeJ

6

Bence ikisi birlikte çalışıyor.

Bağımlılık enjeksiyonu, bazı bağımlı sınıfları / arayüzleri tüketen bir sınıfa (genellikle yapıcısına) ittiğiniz anlamına gelir. Bu, iki sınıfı bir arabirim aracılığıyla ayırır ve tüketen sınıfın birçok "enjekte bağımlılık" uygulamasıyla çalışabileceği anlamına gelir.

Servis bulucunun rolü uygulamanızı bir araya getirmektir. Programın başlangıcında bazı önyükleme çemberleri aracılığıyla bir servis bulucu ayarlarsınız. Önyükleme, bir tür uygulamayı belirli bir özet / arabirimle ilişkilendirme işlemidir. Hangi çalışma zamanında sizin için yaratılır. (yapılandırmanıza veya önyüklemenize göre). Bağımlılık enjeksiyonu uygulamadıysanız, bir servis bulucu veya IOC kabı kullanmak çok zor olacaktır.


6

Eklemek için bir neden, geçen hafta MEF projesi için yazdığımız bir dokümantasyon güncellemesinden esinlenerek (MEF'in oluşturulmasına yardımcı oluyorum).

Bir uygulama potansiyel olarak binlerce bileşenden oluştuğunda, belirli bir bileşenin doğru bir şekilde başlatılıp başlatılamayacağını belirlemek zor olabilir. "Doğru bir şekilde somutlaştırılmış" ile, bu örnekte Foobileşene dayalı , bir örneği IBarve kullanılabilir olacak ve bunu sağlayan bileşenin:

  • gerekli bağımlılıkları var,
  • geçersiz bağımlılık döngülerine dahil edilmemeleri ve
  • MEF durumunda, yalnızca bir örnekle birlikte tedarik edilir.

Yapıcı bağımlılıklarından almak için IoC kapsayıcı gider Verdiğin ikinci örnekte, olarak, bir örneği olduğunu test tek yolu Foodoğru örneklenemez mümkün olacak uygulamanızın gerçek çalışma zamanı yapılandırma ile etmektir aslında yapı o .

Bu, test zamanında her türlü garip yan etkiye sahiptir, çünkü çalışma zamanında çalışacak kodun bir test koşumu altında çalışması gerekmez. Alaylar yapmaz, çünkü gerçek yapılandırma, bazı test zamanı kurulumları değil, test etmemiz gereken şeydir.

Bu sorunun kökü, @Jon tarafından zaten çağrılan farktır: ikinci sürüm zorunlu Hizmet Bulucu desenini kullanırken, yapıcı aracılığıyla bağımlılıkları enjekte etmek bildiricidir.

Bir IoC kapsayıcısı, dikkatle kullanıldığında, ilgili bileşenlerin herhangi bir örneğini oluşturmadan uygulamanızın çalışma zamanı yapılandırmasını statik olarak analiz edebilir. Birçok popüler kap, bunun bazı varyasyonlarını sağlar; .NET 4.5 web ve Metro tarzı uygulamaları hedefleyen MEF sürümü olan Microsoft.Composition , CompositionAssertwiki belgelerinde bir örnek sağlar . Bunu kullanarak, aşağıdaki gibi bir kod yazabilirsiniz:

 // Whatever you use at runtime to configure the container
var container = CreateContainer();

CompositionAssert.CanExportSingle<Foo>(container);

( Bu örneğe bakın ).

Test zamanında uygulamanızın Kompozisyon Köklerini doğrulayarak , işlemin ilerleyen aşamalarında testlerden geçebilecek bazı hataları yakalayabilirsiniz.

Umarım bu konu hakkındaki kapsamlı cevaplara ilginç bir ektir!


5

Not: Soruyu tam olarak cevaplamıyorum. Ancak bunun, bu sayfaya rastlayan Servis Bulucu (anti-) kalıbıyla karıştırılan Bağımlılık Enjeksiyon kalıbının yeni öğrencileri için yararlı olabileceğini hissediyorum .

Servis Bulucu (şimdi bir anti-desen olarak kabul ediliyor) ve Bağımlılık Enjeksiyon desenleri arasındaki farkı biliyorum ve her bir deseni somut örnekleri anlayabiliyorum, ancak yapıcı içinde bir servis bulucu gösteren örneklerle kafam karıştı (varsayalım ' yapıcı enjeksiyon yapıyor).

"Servis Konum Belirleyici" genellikle hem bir modelin adı hem de bu modelde yeni işleç kullanılmadan nesne elde etmek için kullanılan nesneye atıfta bulunmak (aynı zamanda varsayalım) adı olarak kullanılır. Şimdi, aynı tipte bir nesne, bağımlılık enjeksiyonunu gerçekleştirmek için kompozisyon kökünde de kullanılabilir ve karışıklık burada devreye girer.

Burada dikkat edilmesi gereken nokta, bir DI yapıcısının içinde bir servis bulucu nesnesi kullanıyor olabilirsiniz, ancak "Servis Bulucu desenini" kullanmamanızdır. Birinin onu bir IoC kap nesnesi olarak ifade etmesi daha az kafa karıştırıcıdır, çünkü aslında aynı şeyi yaptıklarını tahmin etmiş olabilirsiniz (yanlışsam beni düzeltin).

Bir servis bulucu (veya sadece konumlandırıcı) olarak mı yoksa bir IoC kapsayıcısı (veya sadece kapsayıcı) olarak mı adlandırılacağı, muhtemelen aynı soyutlamaya atıfta bulundukları için tahmin ettiğiniz gibi bir fark yaratmaz (yanlışsam beni düzelt ). Sadece bir servis bulucu olarak adlandırılması, bir kişinin Servis Bulucu anti-desenini Bağımlılık Enjeksiyon deseniyle birlikte kullandığını gösterir.

IMHO, 'konum' veya 'konum' yerine 'konumlandırıcı' olarak adlandırılırken, bazen bir makaledeki hizmet konum belirleyicisinin Hizmet Konum Belirleyici (anti-) desenine değil Hizmet Konumlandırıcı kapsayıcıya başvurduğunu düşünmesine neden olabilir. özellikle Bağımlılık Enjektörü değil, Bağımlılık Enjeksiyonu adı verilen ilgili bir model olduğunda.


4

Bu aşırı basitleştirilmiş durumda hiçbir fark yoktur ve bunlar birbirinin yerine kullanılabilir. Ancak, gerçek dünya sorunları o kadar basit değildir. Bar sınıfının kendisinin D adında başka bir bağımlılığı olduğunu varsayalım. Bu durumda servis bulucunuz bu bağımlılığı çözemez ve bunu D sınıfı içinde başlatmanız gerekir; çünkü bağımlılıklarını somutlaştırmak sınıflarınızın sorumluluğundadır. D sınıfının kendisinin başka bağımlılıkları olsaydı daha da kötüleşirdi ve gerçek dünyadaki durumlarda genellikle bundan daha da karmaşıklaşır. Bu tür senaryolarda DI, ServiceLocator'dan daha iyi bir çözümdür.


4
Hmm katılmıyorum: servis bulucu eski. açıkça orada bir bağımlılık olduğunu gösteriyor ... servis bulucu. Eğer barsınıfın kendisinin bir bağımlılığı varsa, o barzaman servis bulucu da olacaktır, bu DI / IoC kullanmanın bütün mesele.
GFoley83

2

Bağımlılık Enjeksiyonu ve Servis Bulucu arasındaki fark (varsa) nedir? Her iki örüntü de Bağımlılık Tersine Çevirme ilkesini uygulamada iyidir. Genel konumdaki değişiklikleri zorlamaksızın genel tasarımın daha gevşek olmasını sağladığından, Servis Bulucu deseninin mevcut bir kod tabanında kullanımı daha kolaydır. Aynı nedenden dolayı, Servis Bulucu desenine dayanan kod, Bağımlılık Enjeksiyonuna dayanan eşdeğer koddan daha az okunabilir.

Bağımlılık Enjeksiyonu kalıbı, bir sınıfın (veya bir yöntemin) hangi bağımlılıklara sahip olacağının imzasını açıklığa kavuşturur. Bu nedenle, ortaya çıkan kod daha temiz ve daha okunabilir.


1

Basit bir anlayışın ardından Servis Bulucu ve DI Kapsayıcı arasındaki farkı daha iyi anladım:

  • Servis Bulucu tüketici kullanılır ve çeker doğrudan tüketicinin isteği ile bazı depodan kimliğe göre hizmet

  • DI Konteyner yere dışında bulunan ve bazı depodan hizmet ve alır iter (yapıcısı aracılığıyla veya yöntemle olursa olsun) tüketiciye onları

Ancak, bunlar arasındaki farktan sadece somut tüketici kullanımı bağlamında bahsedebiliriz. Kompozisyon kökünde Servis Bulucu ve DI Kabı kullanıldığında, neredeyse benzerdirler.


0

DI kabı, servis bulucu için bir üst kümedir. Bağımlılık enjeksiyonlarını monte etme (kablolama) özelliğine sahip bir servisi bulmak için kullanılabilir .


-2

Kayıt için

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

Gerçekten bir arabirime ihtiyacınız olmadığı sürece (arabirim birden fazla sınıf tarafından kullanılır), KULLANMAMALISINIZ . Bu durumda, IBar onu uygulayan herhangi bir hizmet sınıfının kullanılmasına izin verir. Ancak, genellikle, bu Arayüz tek bir sınıf tarafından kullanılacaktır.

Arayüz kullanmak neden kötü bir fikirdir? Çünkü hata ayıklamak gerçekten zor.

Örneğin, "bar" örneğinin başarısız olduğunu varsayalım, soru: hangi sınıf başarısız oldu? Hangi kodu düzeltmeliyim? Basit bir görünüm, bir Arayüz'e yol açar ve burada yolumun bittiği yer.

Bunun yerine, kod zor bir bağımlılık kullanıyorsa, bir hata ayıklamak kolaydır.

//Foo Needs an IBar
public class Foo
{
  private BarService bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

"Bar" başarısız olursa, o zaman kontrol ve sınıf BarService ateş gerekir.


1
Sınıf, belirli bir nesneyi oluşturmak için kullanılan bir taslaktır. Öte yandan bir arabirim contracta'dır ve sadece eylemi değil bir davranışı tanımlar. Gerçek nesnenin etrafından geçmek yerine, yalnızca arabirim paylaşılır, böylece tüketici nesnenizin geri kalanına erişemez. Ayrıca birim testi için sadece test edilmesi gereken parçanın test edilmesine yardımcı olur. Sanırım zamanla yararlılığını anlarsın.
Gunhan
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.