سلام! جڏهن ته JavaRush انتظاميه نئين سطح تي ڪم ڪري رهي آهي، آئون بهار جي فريم ورڪ تي تربيتي مضمونن جو هڪ سلسلو شروع ڪرڻ چاهيان ٿو. ها، مان ڄاڻان ٿو ته انٽرنيٽ تي هن موضوع تي اڳ ۾ ئي تمام گهڻو مواد آهي، پر، عملي طور ڏيکاري ٿو، اهي سڀئي هيلو ورلڊ ليول تي آهن. مان ڳالهائڻ نه ٿو چاهيان ته ڪيئن صحيح طريقي سان تشريحون رکي، پر اهو سڀ ڪجهه ڪيئن ڪم ڪري ٿو "هوڊ هيٺ". مضمون انھن لاء آھي جيڪي اڳ ۾ ئي ھڪڙي طريقي سان ھن فريم ورڪ سان ڪم ڪري چڪا آھن ۽ بنيادي تصورن کان واقف آھن.
شروعاتي حوالي سان.
سو اچو ته بنيادي ڳالهين سان شروع ڪريون. منهنجي خيال ۾، هڪ تمام اهم نقطو اهو سمجهڻ آهي ته ڪيئن سياق و سباق کي ترتيب ڏنو ويو آهي ۽ بينن جي شروعات ڪئي وئي آهي. جئين توهان کي خبر آهي، بهار ڪم ڪرڻ کان اڳ، ان کي ترتيب ڏيڻ جي ضرورت آهي. اڳئين زماني ۾، اهو ڪيو ويو xml فائلن جي استعمال سان (ڪجهه منصوبن تي، خاص طور تي پراڻا، اهي اڄ ڏينهن تائين جاري آهن). هتي اهڙي ترتيب واري فائيل جو هڪ ننڍڙو مثال آهي:<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<bean id="helloWorld" class="ru.javarush.HelloWorld">
<property name="message" value="Hello World!"/>
</bean>
</beans>
گهڻو ڪري، اهو ڪافي آهي ڪنٽرولر جي هڪ جوڙي ٺاهڻ ۽ هڪ شروعاتي شروع ڪرڻ (جيڪو بند نه ٿيندو). پر هي ترتيب ڪيئن بهار جو ڪم ڪندو؟ ۽ هتي آهي جتي شيون دلچسپ ٿي وڃن ٿيون. اسان جي تشڪيل لاءِ بهار کي سمجھڻ لاءِ، اتي آھي XmlBeanDefinitionReader
. BeanDefinition
ھي ھڪڙو اندروني اسپرنگ جزو آھي جيڪو اسڪين ڪري ٿو (پارس) xml ۽ ٺاھي ٿو ان جي بنياد تي جيڪو اسان اتي لکيو آھي . BeanDefinition
هڪ شئي آهي جيڪا ٻوٽي بابت معلومات محفوظ ڪري ٿي. ھن ۾ شامل آھي: جنھن طبقي مان اھو (بين) ٺاھيو وڃي. گنجائش؛ ڇا سست شروعاتي نصب ٿيل آهي؛ ڇا اهو ضروري آهي ته ان کان اڳ شروع ڪرڻ ضروري آهي ٻي ۽ ٻيون خاصيتون جيڪي xml ۾ بيان ڪيون ويون آهن. سڀ وصول ڪيا ويا BeanDefinition
آهن شامل ڪيا ويا آهن HashMap
، جنهن ۾ سڃاڻپ ڪندڙ بيئن جو نالو آهي (توهان طرفان مقرر ڪيل يا اسپرنگ طرفان مقرر ڪيل) ۽ BeanDefinition
خود اعتراض. هر شي BeanDefinition
پيدا ٿيڻ کان پوء، اسٽيج تي هڪ نئون هيرو ظاهر ٿئي ٿو - BeanFactory
. هي اعتراض HashMap’e
s تي ورجائي ٿو BeanDefinition
، انهن جي بنياد تي بينز ٺاهي ٿو ۽ انهن کي IoC ڪنٽينر ۾ وجهي ٿو. هتي هڪ nuance آهي، حقيقت ۾، جڏهن ايپليڪيشن شروع ٿئي ٿي، IoC ڪنٽينر تي مشتمل هوندي جن ۾ هڪ سنگلٽن اسڪوپ هوندو آهي (ڊفالٽ طور تي مقرر ڪيو ويندو آهي)، جڏهن ته باقي ٺاهيا ويندا آهن جڏهن انهن جي ضرورت هجي (پروٽوٽائپ، درخواست، سيشن). ۽ هاڻي هڪ ننڍڙو تڪرار، اچو ته هڪ ٻئي ڪردار سان واقف ٿي.
BeanPostProcessor سان ملو. (بي پي پي)
حقيقت اها آهي ته هڪ بين ضروري طور تي توهان جي ايپليڪيشن لاء ڪاروباري منطق جو هڪ طبقو ناهي. هڪ بين کي انفراسٽرڪچر بين پڻ سڏيو ويندو آهي. مختصر ۾، هڪ انفراسٽرڪچر بين هڪ ڪلاس آهي جيڪو توهان جي ڪاروباري منطق کي ترتيب ڏئي ٿو (ها، تمام گهڻيون شيون). مان توھان کي ھيٺ ڏنل ان بابت وڌيڪ ٻڌايان ٿو، پر اھو ٿورو واضح ڪرڻ لاءِ ته بي پي پي ڇا ترتيب ڏئي ٿي، مان ھڪڙو مثال ڏيندس. ڇا هرڪو واقف آهي خلاصو سان@Autowired
؟ تنهن ڪري، توهان AutowiredAnnotationBeanPostProcessor
ذميوار آهيو انهي کي يقيني بڻائڻ ته توهان جا سڀئي طبقا هڪ ٻئي ۾ شامل آهن.
اچو ته BeanFactory ڏانهن واپس وڃو
BPP جي باري ۾ هاڻي ڄاڻڻ ضروري آهي، اهو واضح ڪرڻ ضروري آهي ته جڏهنHashMap
's' تي ورجائي رهيا آهن، BeanDefinition
سڀ کان پهريان ٺاهيا ويندا آهن ۽ الڳ الڳ رکيا ويندا آهن (IoC ڪنٽينر ۾ نه) BeanPostProcessor
. ان کان پوء، اسان جي ڪاروباري منطق جي باقاعده ڀاڄيون ٺاهيا ويا آهن، هڪ IoC ڪنٽينر ۾ رکيا ويا آهن، ۽ انهن جي جوڙجڪ الڳ الڳ ملتوي ٿيل BPPs استعمال ڪندي شروع ٿيندي. ۽ اهو ڪيئن ٿئي ٿو، هر بي پي پي جا 2 طريقا آهن:
postProcessorBeforeInitialization(Object bean, String beanName);
postProcessorAfterInitialization(Object bean, String beanName);
اسان جي bins ذريعي ٻه ڀيرا ورجائي ٿو. پهريون ڀيرو طريقو سڏيو ويندو آهي postProcessorBeforeInitialization
، ۽ ٻيو ڀيرو طريقو سڏيو ويندو آهي postProcessorAfterInitialization
. يقينن اهو سوال پيدا ٿيو آهي ته ٻن طريقن جي ضرورت ڇو آهي، مون کي وضاحت ڪرڻ ڏيو. حقيقت اها آهي ته ڪجهه تشريح تي عمل ڪرڻ لاءِ (جهڙوڪ @Transactional
، مثال طور)، اسان جي بين کي پراکسي ڪلاس سان تبديل ڪيو ويندو آهي. سمجھڻ لاءِ اھو ڇو ڪيو ويو آھي، توھان کي ڄاڻڻ جي ضرورت آھي ته اھو ڪيئن ڪم ڪري ٿو @Transactional
، ۽ اھو ڪيئن ڪم ڪري ٿو. توھان کي ھلڻ تي ھن تشريح سان نشان لڳل طريقي سان ڪوڊ جون ڪجھ وڌيڪ لائينون شامل ڪرڻ جي ضرورت آھي. اهو ڪيئن ڪجي؟ اهو صحيح آهي، هڪ پراڪس ڪلاس ٺاهڻ سان، جنهن جي اندر ضروري ڪوڊ شامل ڪيو ويندو گهربل طريقي سان. ھاڻي ھن صورتحال کي تصور ڪريو، اسان وٽ ھڪڙو طبقو آھي:
class A {
@Autowired
private SomeClass someClass;
@Transactional
public void method() {
// модификатор доступа обязательно public
}
}
ھن ڪلاس ۾ 2 تشريحون @Autowired
۽ @Transactional
. ٻئي تشريحون مختلف BPPs پاران عمل ڪيون وينديون آھن. جيڪڏهن اهو پهريون ڪم ڪري ٿو AutowiredBPP
، ته پوء سڀ ڪجهه ٺيڪ ٿي ويندو، پر جيڪڏهن نه، ته پوء اسان هن مسئلي کي منهن ڪنداسين. حقيقت اها آهي ته جڏهن پراکسي ڪلاس ٺاهي وئي آهي، سڀ ميٽا معلومات گم ٿي ويندي آهي. @Autowired
ٻين لفظن ۾، پروڪسي ڪلاس ۾ تشريح بابت ڪا به ڄاڻ نه هوندي ، ۽ تنهن ڪري AutowiredBPP
اهو ڪم نه ڪندو، جنهن جو مطلب آهي ته اسان جي فيلڊ وٽ someClass
قيمت هوندي null
، جيڪا گهڻو ڪري NPE ڏانهن ويندي. اهو پڻ ڄاڻڻ جي قابل آهي ته طريقن جي ڪالن جي وچ ۾، -ميٿڊ سڏيو ويندو postProcessorBeforeInitialization
آهي ، جيڪڏهن اتي هڪ آهي. ھي بنيادي طور تي ٻيو ٺاھيندڙ آھي، پر فرق اھو آھي ته ھن وقت اسان جا سڀ انحصار اڳ ۾ ئي ڪلاس ۾ شامل آھن ۽ اسان انھن تائين رسائي ڪري سگھون ٿا -method. تنهن ڪري، هڪ ڀيرو ٻيهر حوالي سان شروعاتي الگورتھم: postProcessorAfterInitialization
init
init
XmlBeanDefinitionReader
اسان جي xml ترتيب واري فائل کي اسڪين ڪري ٿو.- ٺاهي ٿو
BeanDefinition
۽ ان ۾ وجهي ٿوHashMap
. - اچي ٿو
BeanFactory
۽ ان مانHashMap
الڳ الڳ سڀني کي شامل ڪري ٿوBeanPostProcessor
. BeanDefinition
مان ڀاڄيون ٺاهي ٿو ۽ انهن کي IoC ڪنٽينر ۾ رکي ٿو.- هتي BPPs اچن ٿا ۽ انهن شين کي 2 طريقن سان ترتيب ڏيو.
- تيار.
GO TO FULL VERSION