हम स्प्रिंग के साथ क्या गलत कर रहे हैं

इस लेख में मैं स्प्रिंग पर चलने वाले एप्लिकेशन के कोड में पाए जाने वाले कुछ एंटीपर्टर्न के बारे में टिप्पणियों को साझा करना चाहता हूं। उन सभी का एक तरीका या कोई अन्य लाइव कोड में सामने आया: या तो मैं मौजूदा कक्षाओं में उनके पास आया, या मैंने सहयोगियों के काम को पढ़ते हुए पकड़ा।

मुझे आशा है कि आप रुचि लेंगे, लेकिन यदि आप पढ़ने के बाद अपने "पापों" को स्वीकार करते हैं और सुधार के मार्ग पर चलते हैं, तो मुझे दोगुना प्रसन्नता होगी। मैं आपसे टिप्पणी में अपने स्वयं के उदाहरण साझा करने का भी आग्रह करता हूं, हम पोस्ट में सबसे उत्सुक और असामान्य जोड़ देंगे।

Autowired

महान और भयानक @Autowired वसंत में एक पूरे युग है। परीक्षण लिखने के बाद भी आप इसके बिना नहीं कर सकते, लेकिन मुख्य कोड में यह (PMSM) स्पष्ट रूप से शानदार है। मेरी हाल की कई परियोजनाओं में, वह बिल्कुल भी नहीं था। लंबे समय तक हमने इस तरह लिखा:

 @Component public class MyService { @Autowired private ServiceDependency; @Autowired private AnotherServiceDependency; //... } 

खेतों और बस्तियों के माध्यम से निर्भरता इंजेक्शन की आलोचना करने के कारणों का पहले ही विस्तार से वर्णन किया गया है, विशेष रूप से यहाँ एक विकल्प कंस्ट्रक्टर के माध्यम से लागू होता है। लिंक के बाद, एक उदाहरण वर्णित है:

 private DependencyA dependencyA; private DependencyB dependencyB; private DependencyC dependencyC; @Autowired public DI(DependencyA dependencyA, DependencyB dependencyB, DependencyC dependencyC) { this.dependencyA = dependencyA; this.dependencyB = dependencyB; this.dependencyC = dependencyC; } 

यह कम या ज्यादा सभ्य दिखता है, लेकिन कल्पना करें कि हमारे पास 10 निर्भरताएं हैं (हां, हां, मुझे पता है कि इस मामले में उन्हें अलग-अलग वर्गों में वर्गीकृत करने की आवश्यकता है, लेकिन अब यह उस बारे में नहीं है)। चित्र अब इतना आकर्षक नहीं है:

 private DependencyA dependencyA; private DependencyB dependencyB; private DependencyC dependencyC; private DependencyD dependencyD; private DependencyE dependencyE; private DependencyF dependencyF; private DependencyG dependencyG; private DependencyH dependencyH; private DependencyI dependencyI; private DependencyJ dependencyJ; @Autowired public DI(/* ... */) { this.dependencyA = dependencyA; this.dependencyB = dependencyB; this.dependencyC = dependencyC; this.dependencyD = dependencyD; this.dependencyE = dependencyE; this.dependencyF = dependencyF; this.dependencyG = dependencyG; this.dependencyH = dependencyH; this.dependencyI = dependencyI; this.dependencyJ = dependencyJ; } 

कोड स्पष्ट रूप से, यह राक्षसी दिखता है।

और यहाँ, कई लोग यहाँ भी भूल जाते हैं वायोलिन बाजनेवाला @Autowired जरूरत नहीं है! यदि किसी वर्ग में केवल एक कंस्ट्रक्टर है, तो स्प्रिंग (> = 4) समझेगा कि इस कंस्ट्रक्टर के माध्यम से निर्भरता को लागू करने की आवश्यकता है। इसलिए हम इसे @AllArgsContructor बदलकर फेंक सकते हैं। या इससे भी बेहतर - @RequiredArgsContructor पर, सभी आवश्यक फ़ील्ड को final से घोषित करने और बहु-थ्रेडेड वातावरण में ऑब्जेक्ट की एक सुरक्षित आरंभीकरण प्राप्त करने के लिए भूल के बिना (बशर्ते कि सभी निर्भरता भी सुरक्षित रूप से आरंभीकृत हो):

 @RequiredArgsConstructor public class DI { private final DependencyA dependencyA; private final DependencyB dependencyB; private final DependencyC dependencyC; private final DependencyD dependencyD; private final DependencyE dependencyE; private final DependencyF dependencyF; private final DependencyG dependencyG; private final DependencyH dependencyH; private final DependencyI dependencyI; private final DependencyJ dependencyJ; } 

उपयोगिता वर्गों और Enum कार्यों में स्टेटिक तरीके

खूनी ई में अक्सर डेटा वाहक वस्तुओं को एक एप्लिकेशन परत से दूसरी परत की समान वस्तुओं में परिवर्तित करने का कार्य होता है। इसके लिए, इस तरह स्थिर तरीकों के साथ उपयोगिता कक्षाएं अभी भी उपयोग की जाती हैं (याद रखें, वर्ष 2019 में):

 @UtilityClass public class Utils { public static UserDto entityToDto(UserEntity user) { //... } } 

स्मार्ट किताबें पढ़ने वाले अधिक उन्नत उपयोगकर्ता गणना के जादुई गुणों से अवगत हैं:

 enum Function implements Function<UserEntity, UserDto> { INST; @Override public UserDto apply(UserEntity user) { //... } } 

सच है, इस मामले में, कॉल अभी भी एकल ऑब्जेक्ट के लिए होता है, और स्प्रिंग द्वारा नियंत्रित घटक के लिए नहीं।
और भी अधिक उन्नत लड़के (और लड़कियां) MapStruct के बारे में जानते हैं, जो आपको एक ही इंटरफ़ेस में सब कुछ वर्णन करने की अनुमति देता है:

 @Mapper(componentModel = "spring", unmappedTargetPolicy = ReportingPolicy.ERROR) public interface CriminalRecommendationMapper { UserDto map(UserEntity user); } 

अब हम वसंत घटक प्राप्त करते हैं। यह एक जीत की तरह लगता है। लेकिन शैतान विवरण में है, और ऐसा होता है कि जीत भारी हो जाती है। सबसे पहले, क्षेत्र के नाम समान होने चाहिए (अन्यथा बवासीर शुरू होते हैं), जो हमेशा सुविधाजनक नहीं होता है, और दूसरी बात, यदि संसाधित वस्तुओं के किसी भी जटिल क्षेत्र परिवर्तन होते हैं, तो अतिरिक्त कठिनाइयां उत्पन्न होती हैं। खैर, मैपस्ट्रैक को केवल निर्भर करने की आवश्यकता है।

और कुछ लोग पुराने जमाने को याद करते हैं, लेकिन फिर भी बसंत-चालित कनवर्टर पाने के लिए सरल और काम करने का तरीका:

 import org.springframework.core.convert.converter.Converter; @Component public class UserEntityToDto implements Converter<UserEntity, UserDto> { @Override public UserDto convert(UserEntity user) { //... } } 

यहाँ लाभ यह है कि एक अन्य वर्ग में, मुझे केवल लिखने की आवश्यकता है

 @Component @RequiredArgsConstructor public class DI { private final Converter<UserEntity, UserDto> userEnityToDto; } 

और वसंत अपने आप ही सब कुछ हल कर देगा!

व्यर्थ का पात्र

जीवन का मामला: आवेदन दो डेटाबेस के साथ काम करता है। तदनुसार, दो डेटा स्रोत ( java.sql.DataSource ), दो लेन-देन प्रबंधक, रिपॉजिटरी के दो समूह आदि हैं। यह सब आसानी से दो अलग-अलग सेटिंग्स में वर्णित है। यह पोस्टग्रे के लिए है:

 @Configuration public class PsqlDatasourceConfig { @Bean @Primary @ConfigurationProperties(prefix = "spring.datasource.psql") public DataSource psqlDataSource() { return DataSourceBuilder.create().build(); } @Bean public SpringLiquibase primaryLiquibase( ProfileChecker checker, @Qualifier("psqlDataSource") DataSource dataSource ) { boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(dataSource); liquibase.setChangeLog("classpath:liquibase/schema-postgre.xml"); liquibase.setShouldRun(isTest); return liquibase; } } 

और यह DB2 के लिए है:

 @Configuration public class Db2DatasourceConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource.db2") public DataSource db2DataSource() { return DataSourceBuilder.create().build(); } @Bean public SpringLiquibase liquibase( ProfileChecker checker, @Qualifier("db2DataSource") DataSource dataSource ) { boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(dataSource); liquibase.setChangeLog("classpath:liquibase/schema-db2.xml"); liquibase.setShouldRun(isTest); return liquibase; } } 

चूंकि मेरे पास दो डेटाबेस हैं, परीक्षणों के लिए मैं उन पर दो अलग-अलग डीडीएल / डीएमएल रोल करना चाहता हूं। चूँकि दोनों कॉन्फ़िगरेशन एक ही समय में लोड होते हैं, जब एप्लिकेशन ऊपर होता है, अगर मैं @Qualifier , तो स्प्रिंग अपना लक्ष्य पदनाम खो देगा और, सबसे अच्छा, विफल हो जाएगा। यह पता चला है कि @Qualifier बोझिल हैं और खरोंच से ग्रस्त हैं, और उनके बिना यह काम नहीं करता है। गतिरोध को तोड़ने के लिए, आपको यह महसूस करने की आवश्यकता है कि निर्भरता न केवल एक तर्क के रूप में प्राप्त की जा सकती है, बल्कि एक वापसी मूल्य के रूप में, इस तरह कोड को फिर से लिखना है:

 @Configuration public class PsqlDatasourceConfig { @Bean @Primary @ConfigurationProperties(prefix = "spring.datasource.psql") public DataSource psqlDataSource() { return DataSourceBuilder.create().build(); } @Bean public SpringLiquibase primaryLiquibase(ProfileChecker checker) { boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(psqlDataSource()); // <----- liquibase.setChangeLog("classpath:liquibase/schema-postgre.xml"); liquibase.setShouldRun(isTest); return liquibase; } } //... @Configuration public class Db2DatasourceConfig { @Bean @ConfigurationProperties(prefix = "spring.datasource.db2") public DataSource db2DataSource() { return DataSourceBuilder.create().build(); } @Bean public SpringLiquibase liquibase(ProfileChecker checker) { boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(db2DataSource()); // <----- liquibase.setChangeLog("classpath:liquibase/schema-db2.xml"); liquibase.setShouldRun(isTest); return liquibase; } } 

javax.inject.Provider

प्रोटोटाइप दायरे के साथ सेम कैसे प्राप्त करें? मैं अक्सर इस पर आता था

 @Component @Scope(SCOPE_PROTOTYPE) @RequiredArgsConstructor public class ProjectBuilder { private final ProjectFileConverter converter; private final ProjectRepository projectRepository; //... } @Component @RequiredArgsConstructor public class PrototypeUtilizer { private final Provider<ProjectBuilder> projectBuilderProvider; void method() { ProjectBuilder freshBuilder = projectBuilderProvider.get(); } } 

ऐसा लगता है कि सब कुछ ठीक है, कोड काम करता है। हालांकि, शहद के इस बैरल में मरहम में एक मक्खी है। हमें एक और javax.inject:javax.inject:1 निर्भरता को खींचने की आवश्यकता है, जो ठीक 10 साल पहले मावेन सेंट्रल में जोड़ा गया था और तब से कभी भी अपडेट नहीं किया गया।

लेकिन वसंत लंबे समय से तीसरे पक्ष के व्यसनों के बिना भी ऐसा ही करने में सक्षम है! बस javax.inject.Provider::get बदलें org.springframework.beans.factory.ObjectFactory::getObject साथ javax.inject.Provider::get org.springframework.beans.factory.ObjectFactory::getObject और सब कुछ उसी तरह काम करता है।

 @Component @RequiredArgsConstructor public class PrototypeUtilizer { private final ObjectFactory<ProjectBuilder> projectBuilderFactory; void method() { ProjectBuilder freshBuilder = projectBuilderFactory.getObject(); } } 

अब हम स्पष्ट विवेक के साथ, निर्भरता की सूची से javax.inject को काट javax.inject ।

सेटिंग्स में कक्षाओं के बजाय स्ट्रिंग्स का उपयोग करना

स्प्रिंग डेटा रिपोजिटरी को एक परियोजना से जोड़ने का एक आम उदाहरण:

 @Configuration @EnableJpaRepositories("com.smth.repository") public class JpaConfig { //... } 

यहां हम स्पष्ट रूप से उस पैकेज को लिखते हैं जो स्प्रिंग द्वारा देखा जाएगा। यदि हम थोड़ा अतिरिक्त नामकरण की अनुमति देते हैं, तो एप्लिकेशन स्टार्टअप पर क्रैश हो जाएगा। मैं शुरुआती चरणों में, कोड के संपादन के दौरान - इस तरह की बेवकूफाना त्रुटियों का पता लगाना चाहता हूं। ढांचा हमारी ओर जाता है, इसलिए ऊपर दिए गए कोड को फिर से लिखा जा सकता है:

 @Configuration @EnableJpaRepositories(basePackageClasses = AuditRepository.class) public class JpaConfig { //... } 

यहाँ AuditRepository पैकेज रिपॉजिटरी में से एक है जिसे हम देख रहे होंगे। चूंकि हमने कक्षा को इंगित किया है, इसलिए हमें इस वर्ग को हमारे कॉन्फ़िगरेशन से कनेक्ट करने की आवश्यकता होगी, और अब टाइपोस को सीधे संपादक में या सबसे कम, परियोजना का निर्माण करते समय पता लगाया जाएगा।

इस दृष्टिकोण को कई समान मामलों में लागू किया जा सकता है, उदाहरण के लिए:

 @ComponentScan(basePackages = "com.smth") 

में बदल जाता है

 import com.smth.Smth; @ComponentScan(basePackageClasses = Smth.class) 

अगर हमें कुछ क्लास को फॉर्म के Map<String, Object> जोड़ना है, तो इसे इस तरह किया जा सकता है:

 void config(LocalContainerEntityManagerFactoryBean bean) { String property = "hibernate.session_factory.session_scoped_interceptor"; bean.getJpaPropertyMap().put(property, "com.smth.interceptor.AuditInterceptor"); } 

लेकिन एक स्पष्ट प्रकार का उपयोग करना बेहतर है:

 import com.smth.interceptor.AuditInterceptor; void config(LocalContainerEntityManagerFactoryBean bean) { String property = "hibernate.session_factory.session_scoped_interceptor"; bean.getJpaPropertyMap().put(property, AuditInterceptor.class); } 

और जब ऐसा कुछ है

 LocalContainerEntityManagerFactoryBean bean = builder .dataSource(dataSource) .packages( //...     ) .persistenceUnit("psql") .build(); 

यह ध्यान देने योग्य है कि packages() पद्धति अतिभारित है और कक्षाओं का उपयोग करती है:

सभी बीन्स को एक पैकेज में न रखें

मुझे लगता है कि स्प्रिंग / स्प्रिंग बूथ पर कई परियोजनाओं में आपने एक समान संरचना देखी है:

 root-package | \ repository/ entity/ service/ Application.java 

यहाँ Application.java की जड़ वर्ग है:

 @SpringBootApplication @EnableJpaRepositories(basePackageClasses = SomeRepository.class) public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } 

यह क्लासिक microservice कोड है: घटकों को उद्देश्य के अनुसार फ़ोल्डरों में व्यवस्थित किया जाता है, सेटिंग्स के साथ वर्ग रूट पर है। जबकि प्रोजेक्ट छोटा है, तो सब कुछ ठीक है। जैसे-जैसे परियोजना बढ़ती है, वसा पैकेज दर्जनों रिपॉजिटरी / सेवाओं के साथ दिखाई देते हैं। और अगर परियोजना एक अखंड बनी हुई है, तो उनके साथ जी.डी. लेकिन अगर कार्य रैग्ड एप्लिकेशन को भागों में विभाजित करने के लिए उठता है, तो प्रश्न शुरू होते हैं। एक बार इस दर्द का अनुभव करने के बाद, मैंने एक अलग दृष्टिकोण लेने का फैसला किया, अर्थात् उनके डोमेन द्वारा समूह कक्षाओं के लिए। परिणाम कुछ इस तरह है

 root-package/ | \ user/ | \ repository/ domain/ service/ controller/ UserConfig.java billing/ | \ repository/ domain/ service/ BillingConfig.java //... Application.java 

यहां, user पैकेज में उपयोगकर्ता तर्क के लिए जिम्मेदार वर्गों के साथ उप-पैकेज शामिल हैं:

 user/ | \ repository/ UserRepository.java domain/ UserEntity.java service/ UserService.java controller/ UserController.java UserConfig.java 

अब UserConfig आप इस कार्यक्षमता से जुड़ी सभी सेटिंग्स का वर्णन कर सकते हैं:

 @Configuration @ComponentScan(basePackageClasses = UserServiceImpl.class) @EnableJpaRepositories(basePackageClasses = UserRepository.class) class UserConfig { } 

इस दृष्टिकोण का लाभ यह है कि, यदि आवश्यक हो, तो मॉड्यूल को आसानी से अलग सेवाओं / अनुप्रयोगों के लिए आवंटित किया जा सकता है। यह भी उपयोगी है यदि आप अपनी परियोजना को module-info.java जोड़कर, बाहर की दुनिया से उपयोगिता कक्षाओं को छिपाते हुए module-info.java करना चाहते हैं।

मुझे उम्मीद है कि मेरा काम आपके लिए उपयोगी रहा है। टिप्पणियों में अपने एंटीपर्ट्स का वर्णन करें, हम इसे एक साथ हल करेंगे :)