Spring @Otomatik kullanım

@Autowired'i Spring tarafından bağlanacak bir sınıfta kullanmanın avantajları ve dezavantajları nelerdir?

Sadece açıklığa kavuşturmak için, özellikle XML'de otomatik kablolamadan değil , @Autowired ek açıklamasından bahsediyorum .

Muhtemelen anlamıyorum, ama bana göre neredeyse bir anti-desen gibi görünüyor - sınıflarınız sadece POJO'lar olmaktan ziyade bir DI çerçevesine bağlı olduklarının farkına varmaya başlıyor. Belki ceza için bir oburum, ama fasulye için harici XML yapılandırmasına sahip olmayı seviyorum ve açık kablolara sahip olmayı seviyorum, bu yüzden tam olarak nerede kablolu olduğunu biliyorum.

Uzun zamandır hepimizin kullandığı xml dosyaları gibi "merkezi, bildirimsel bir yapılandırmaya" sahip olmanın bir değeri olduğuna inandım. Sonra dosyalardaki şeylerin çoğunun yapılandırma olmadığını fark ettim - geliştirmeden sonra hiçbir yerde değişmedi. Sonra fark ettim ki "merkezileştirilmiş" sadece oldukça küçük sistemlerde bir değere sahiptir - sadece küçük sistemlerde bir bütün olarak bir yapılandırma dosyasını görüntüleyebileceksiniz . Ve aynı "kablolar" çoğunlukla koddaki bağımlılıklar tarafından çoğaltıldığında kablolamayı bir bütün olarak anlamanın değeri nedir? Bu yüzden tuttuğum tek şey, hala bir tür bildirici olan meta verilerdir (ek açıklamalar). Bunlar çalışma zamanında asla değişmez ve asla "yapılandırma" veri anında değişecek - bu yüzden kodda tutmak güzel olduğunu düşünüyorum.

Tam otomatik kablolamayı olabildiğince kullanıyorum. Onu seviyorum. Silah noktasında tehdit edilmediği sürece eski tarz ilkbahara geri dönmeyeceğim. Tamamen tercih etme nedenlerim @Autowiredzamanla değişti.

Şu anda, otomatik kablolamayı kullanmanın en önemli nedeninin sisteminizde izlenecek daha az bir soyutlama olduğunu düşünüyorum. "Fasulye adı" etkin bir şekilde kayboldu. Fasulye adının sadece xml nedeniyle var olduğu ortaya çıkıyor. Böylece soyut indirimlerden oluşan tam bir katman (fasulye adı "foo" yu fasulyenin "çubuğuna" bağlarsınız) kaybolur. Şimdi "Foo" arayüzünü doğrudan fasulyeme bağlarım ve uygulama çalışma zamanı profiline göre seçilir. Bu, bağımlılıkları ve uygulamaları izlerken kodla çalışmama izin veriyor . Kodumda otomatik kablolu bir bağımlılık gördüğümde sadece IDE'mde "uygulamaya git" tuşuna basabilirim ve yukarıda bilinen uygulamalar listesi gelir. Çoğu durumda sadece bir uygulama vardır ve ben doğrudan sınıfa giriyorum. Yapabilmek' ne uygulama kullanılıyor (Xml kablolama ile tersi gerçeğe daha yakın olduğunu iddia ediyorum - komik bakış açınızı nasıl değiştirir!)

Şimdi bunun çok basit bir katman olduğunu söyleyebiliriz, ancak sistemlerimize eklediğimiz her soyutlama katmanı karmaşıklığı artırır . Gerçekten xml hiç çalıştığım herhangi bir sisteme herhangi bir gerçek değer kattığını sanmıyorum.

Şimdiye kadar çalıştığım çoğu sistemin üretim çalışma ortamı için yalnızca bir yapılandırması var . Test ve benzeri için başka yapılandırmalar olabilir.

Tam otomatik kablolamanın baharın yakut rayları olduğunu söyleyebilirim: Çoğu kullanım vakasının takip ettiği normal ve ortak bir kullanım modeli olduğu fikrini kucaklar. XML yapılandırmasıyla , amaçlanabilecek / edilmeyebilecek birçok tutarlı / tutarsız yapılandırma kullanımına izin verirsiniz . Ben çok fazla xml yapılandırma tutarsızlıklar ile denize gitmek gördüm - kod ile birlikte refactored olsun? Düşünmedim. Bu varyasyonlar bir nedenden dolayı mı? Genellikle hayır.

Yapılandırmamızda niteleyicileri çok az kullanıyoruz ve bu durumları çözmek için başka yollar bulduk. Bu, karşılaştığımız açık bir "dezavantaj" dır: Kodlamayı otomatik kablolama ile daha sorunsuz etkileşime sokmak için biraz değiştirdik: Bir müşteri havuzu artık genel Repository<Customer>arayüzü uygulamıyor ancak genişleyen bir arayüz CustomerRepositoryoluşturuyoruz Repository<Customer>. Bazen alt sınıfa gelince bir iki numara daha vardır. Ancak genellikle bizi daha güçlü yazma yönüne yönlendirir, ki bulduğum neredeyse her zaman daha iyi bir çözümdür.

Ama evet, çoğunlukla baharın yaptığı belirli bir DI stiline bağlısınız. Bağımlılıklar için artık kamu ayarlayıcıları bile yapmıyoruz (Yani kapsülleme / bilgi gizleme bölümünde +1 olduğumuzu iddia edebilirsiniz) Sistemimizde hala bazı xml'lerimiz var, ancak xml temel olarak sadece anomalileri içeriyor. Tam otomatik kablolama xml ile güzel bir şekilde bütünleşir.

Şimdi ihtiyacımız olan tek şey @Component, @Autowiredve geri kalanının bir JSR'ye ( JSR-250 gibi ) dahil edilmesi için, bu yüzden bahar ile bağlanmak zorunda değiliz. Bu şeyler geçmişte gerçekleşiyor ( java.util.concurrentşeyler akla yayılıyor), bu yüzden bu tekrar olsaydı tamamen şaşırmazdım.

Benim için burada Bahar ve otomatik kablolama hakkında sevdiğim / sevmediğim şey.

Artıları:

• Otomatik kablolama, kötü XML yapılandırmasından kurtulur.
• Alanları, ayarlayıcı yöntemleri veya yapıcıları kullanarak doğrudan enjekte etmenizi sağlayan ek açıklamaları kullanmak çok daha kolaydır. Ayrıca enjekte edilen fasulye açıklama ve 'nitelendirmek' için izin verir.

Eksileri:

• Otomatik kablolama ve ek açıklamalar kullanmak, XML yapılandırmasında olduğu gibi Spring ile veya Spring olmadan çalışmayı seçebileceğiniz Spring kitaplıklarına bağımlı olmanızı sağlar. Dediğiniz gibi, bir DI çerçevesine bağlısınız.
• Aynı zamanda fasulyeleri 'niteleyebilmeyi' seviyorum, bana göre bu kod gerçekten dağınık. Aynı fasulyeyi birden fazla yere enjekte etmeniz gerekiyorsa, aynı dize adının her yerde tekrarlandığını gördüm. Bana göre bunun hata potansiyeli var gibi görünüyor.

Neredeyse sadece iş yerinde otomatik kablolamayı kullanmaya başladım çünkü zaten Bahar entegrasyonuna çok bağımlıyız, çünkü bağımlılık sorunu tartışmalı. Otomatik kablolamayı yaygın olarak kullanan ve kafamı sarmak biraz zor olan bir Spring MVC projesinde çalıştım.

Otomatik kablolamanın edinilmiş bir tat olduğunu düşünüyorum, buna alıştığınızda XML yapılandırmasından daha güçlü, kolay ve çok daha az baş ağrısının olduğunu anlıyorsunuz.

Büyük projemizde @Autowire'dan XML yapılandırmasına geri dönüyoruz. Sorun çok düşük önyükleme performansıdır. Otomatik kablolama tarayıcısı, otomatik kablolama arama sınıfyolundan tüm sınıfları yükler, bu nedenle, Bahar başlatması sırasında birçok sınıf hevesle yüklenir.

Anahtarlama ortamları hakkında çok az tartışma yapılmıştır. Üzerinde çalıştığım çoğu proje üzerinde çalıştığımız ortama bağlı olarak bağımlılıklar enjekte etmek gerçek bir konuydu. Xml config ile Spring EL ile oldukça basit ve ek açıklamalarla güzel bir çözümün farkında değilim. Az önce bir tane buldum:

    @Value("#{${env} == "production" ? realService : dummyService}")
    private SomeService service;

Çalışıyor olmalı ama güzel bir çözüm değil imho.

@Otomatikwire'a geçtim. XML yapılandırmasını küçük bir proje dışında herhangi bir şey üzerinde tutmak, kendi başına bir görev haline geldi ve kavrama hızla bozuldu.

IntelliJ, Bahar ek açıklamaları için iyi (mükemmel değil) destek sağlar.

Bu konudaki benim, xml yapılandırmasının özellikle büyük sistemlerde kodun netliğini azaltması.

@Component gibi ek açıklamalar işleri daha da kötüleştirir. Varsayılan kurucuların sağlanması gerektiği düşünüldüğünde, bağımlılıklar artık nihai hale getirilemediğinden, geliştiricileri nesneleri değiştirmeye yönlendirir. Bağımlılıkların ya kamu ayarlayıcı aracılığıyla enjekte edilmesi ya da @Autowired aracılığıyla kontrol edilmemesi gerekir. [daha da kötü bağımlılık enjeksiyonu, bağımlılıklarını başlatan sınıflarla tehlikeye atılır, bunu yine de yeni yazılı kodda görüyorum!]. Kontrolsüz demek istediğim, büyük sistemlerde, bu türden birden fazla uygulama (ya da çocuk) mevcut olduğunda, uygulamaların hangilerinin araştırılmasının hatalarını daha zorlaştıran bir karmaşıklık olan @Autowired olduğunu anlamak çok daha karmaşık hale gelir. Aynı zamanda, test ortamı için bir profiliniz ve üretim için başka bir profiliniz olduğu anlamına gelir.

Yapılandırma sınıflarımı bildirdiğim orta yere bağlı kalıyorum, (@Configuration kullanarak java tabanlı Spring yapılandırması)

Tüm fasulyelerimi açıkça konfigürasyon sınıf (lar) ında beyan ederim. Yalnızca yapılandırma sınıf (lar) ında @Autowired kullanıyorum, amaç Yapılandırma sınıf (lar) ına olan Bahar bağımlılığını sınırlamak

@Yapılandırma, belirli bir paket içinde bulunur; bu, bahar taramasının çalıştığı tek yerdir. (Bu, büyük projelerde başlangıç ​​süresini önemli ölçüde hızlandırır)

Tüm sınıflarımı değişmez kılmaya çalışıyorum, özellikle veri nesnesi, JPA, Hibernate ve Spring, ayrıca birçok serileştirme kütüphanesi bunu zayıflatıyor gibi görünüyor. Beni ayarlayıcı sağlamaya zorlayan herhangi bir şeyden uzaklaşıyorum ya da son anahtar kelimeyi mülk beyanımdan kaldırıyorum.

Nesneler oluşturulduktan sonra değiştirilme olasılıklarını azaltmak, büyük sistemdeki hataları önemli ölçüde azaltır ve bir tane olduğunda bir hata bulma süresini azaltır.

Ayrıca geliştiriciyi sistemin farklı bölümleri arasındaki etkileşimi daha iyi tasarlamaya zorluyor gibi görünüyor. Sorunlar ve hatalar gittikçe daha fazla derleme hatası haline gelir, bu da boşa harcanan zamanı azaltır ve verimliliği artırır.

İşte bazı deneyim
artıları

• @Autowire ek açıklamasını kullanabileceğimiz için yapılandırılması daha kolay
• Setter yöntemlerini kullanmak istemiyorum, bu yüzden sınıf daha temiz olacak

Eksileri

• DI kullanıyor olsak bile sıkıca xml dosyasını birleştiriyoruz
• Uygulama bulmak zor (Ama eğer intellij gibi iyi ifadeler kullanıyorsanız bundan kurtulabilirsiniz)

Kişisel deneyimlerim itibariyle @AutoWire ek açıklamasını o kadar çok kullanmadım ama test senaryolarında.

XML yerine ek açıklamalarla yazmayı gerçekten çok seviyorum. Spring kılavuzuna ve son sürümlerine göre, XML ve Ek Açıklama aynı sonucu elde etti.

Bu benim listem

Pro:

• Yararsız satırı xml'den kaldır
• Kodda hata ayıklamayı basitleştirin: bir sınıfı açtığınızda, sınıfta neler olduğunu okuyabilirsiniz
• Daha hızlı gelişen, 400 veya daha fazla XML satırına sahip bir proje okunabilir mi?

Eksileri:

• Standart Java uygulaması değil, ancak bir Java Standart Api olan @Inject kullanmaya geçebilirsiniz, böylece fasulye bir Pojo olarak kalır
• Sadece her yerde kullanamazsınız, db bağlantısı vb, ancak bu sadece bir görüş, ben tüm yapılandırma okumak bir yer var tercih ederim.

Benim anlayışım için @Autowired arayüz referansı ve geçersiz kılma işlevlerini kullanırken kullanmak için en iyisidir, ancak bununla ilgili bir sorun buluyorum, bazen çalışma zamanında null olarak atanmış olmasıdır.