Bir fasulyeyi somutlaştırmak için Spring ne zaman kullanılmaz?

Baharın doğru kullanımının ne olacağını anlamaya çalışıyorum. Sözdizimsel olarak değil, amacı açısından. Biri Spring kullanıyorsa, Spring kodu tüm fasülye instantiation kodunu değiştirmeli mi? Bir fasulyeyi başlatmak için ne zaman kullanılmalı veya ne zaman kullanılmamalıdır?

Aşağıdaki kod örneği ikilemi anlamanıza yardımcı olabilir:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

Ben Bahar yapılandırmak gibi bir şey olur:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

Şahsen Spring'i burada kullanmanın gereksiz bir yük olduğunu düşünüyorum, çünkü

1. Kodun okunması / anlaşılması daha kolaydır.
2. Bağımlılık Enjeksiyonu için gerçekten iyi bir yer değil, çünkü çoklu / çeşitli bir uygulama ClassAolacağını, daha sonra bahar konfigürasyonunu kullanarak değiştirme özgürlüğünün olmasını beklemiyorum .

Doğru mu düşünüyorum? Değilse, nerede yanlış gidiyorum?

Haklısın, Bahar listelediğin kullanım durumu için uygun değil. Spring, harici bağımlılıkları (bir JDBC bağlantısını DAO'ya bağlamak gibi) veya yapılandırmaları (hangi veritabanı türünün kullanılacağını belirtmek gibi) yönetmek için daha iyi kullanılır. Örneğinizde, fasulye türü değişebiliyorsa, çekirdeği belirtmek için bir arabirim kullanırsınız ve bir Fabrika kullanarak çekirdekleri başlatırsınız. Hangi fabrikayı kullanacağınızı belirtmek için Spring'i kullanırsınız ve fasulyeleri somutlaştırmak için gereken sınıfa enjekte edersiniz. Daha sonra, birkaç farklı fasulye türü oluşturan (hepsi fasulye arayüzünü destekleyen) birkaç farklı fabrikaya sahip olabilir ve kurulum (veya güncelleme) zamanında uygun olanı yapılandırabilirsiniz.

Katmanlar arasında Spring (veya başka bir DI sistemi), katmanlar içinde doğrudan örnekleme kullanırım.
Bu nedenle, söz konusu sınıfın kapsamını, muhtemelen bu sistem veya bazı iletişim katmanı tarafından tanımlanan bazı (işlevsel olarak) harici sisteme bırakan bir fasulye oluşturan bir sınıf DI yoluyla yaratılacaktır. Yalnızca uygulama katmanı içinde dahili kullanım için yaratılan bir başka fasulye, hem kod netliği hem de (büyük sistemlerde olduğu gibi) performans nedenleriyle doğrudan yaratılır.

Eğer bir fasulye ise , Spring'in onu inşa etmesine izin vermelisiniz (bir fabrika fasulyesi tedarik edebilmeniz dışında - bir sistem özelliğine bağlı belirli bir alt sınıfı geri vermem gerektiğinde kullandım - @Configurationve @Beanek açıklamalara ve belgelere başvurmalısınız. eğer bunu yapıyorsanız). Fasulye değil, sadece Düz Eski Java Nesnesi ise, bunu yapmak için Spring'i kullanmanıza gerek yoktur. POJO'lar faydalıdır, ancak Spring'in sizin için eklediği şeyler olduğu için bağımlılık enjeksiyonu, AOP sarmalayıcıları vb.

Temel karar, gerçekten bir fasulye mi yoksa bazı fasulye sözleşmelerini takip eden sıradan bir nesne mi (örn. Yöntem adlandırma) olup olmadığıdır. Sanırım verdiğiniz küçük örnekte durum böyle.

Yanlış uzman olabilirim, lütfen düzeltin.

Bahar bağlamında tüm Fasulye kavramı Bahar Konteyner nesnenin ilgileniyor olmasıdır. Doğuş, kapsam yaşam döngüsü ölümü vb ... Nesnenin bekçisi gibi. İhtiyacı olan uygulama enjekte eder.

Bu nedenle, modülünüzün tasarımı sırasında karar verirken her zaman Spring çerçevesinin ilgilenmesini isteyip istemediğinizi düşünün ya da yaşam döngüsü bir yönteme dahil edilen basit bir nesne.

Daha önce önerildiği gibi dao nesneleri jms kuyruk nesneleri vb ağır ve daha iyi Bahar çerçeve uzmanı bırakılır.