CDI ဆိုတာ Context And Dependency Injection ဆိုတဲ့ အမည်ရဲ့ အတိုကောက်အမည် တစ်ခုဖြစ်ပြီး၊ Context ဆိုတဲ့ Service နဲ့ Dependency Injection ဆိုတဲ့ Service တို့ကို အဓိက ပံ့ပိုးပေးထားတဲ့ API လဲ ဖြစ်ပါတယ်။
Context ဆိုတာက Object တွေရဲ့ Lifecycle ကို Container မှ Manage လုပ်ပေးနိုင်ပြီး၊ ထို Object တွေဟာလဲ Well Define ဖြစ်တဲ့ Scope တွေမှာ အသုံးပြုနိုင်အောင် ဆောင်ရွက်ပေးနိုင်တယ်။ တဖန် ထို Object တွေရဲ့ Lifecycle တစ်လျောက်လုံးမှာ အသုံးပြုနေတဲ့ Object တွေကိုလဲ သူနဲ့အတူတကွ အလုပ်လုပ်နိုင်အောင် ဆောင်ရွက်ပေးနိုင်တဲ့ Service ဖြစ်ပါတယ်။
Context Service ကြောင့် Java EE မှာ အသုံးပြုနေတဲ့ Component တွေကို ဘယ် Client က အသုံးပြုနေတယ်ဆိုတာကို ခွဲခြား သတ်မှတ်နိုင်ပြီး မသက်ဆိုင်တဲ့ Communicate မလုပ်အောင် စီမံပေးနိုင်မှာ ဖြစ်ပါတယ်။
Dependency Injection ဆိုတာကတော့ ထင်ရှားတဲ့ Design Pattern တစ်ခုဖြစ်ပြီး၊ Java EE ပတ်ဝန်းကျင်မှာ အသုံးပြုလိုတဲ့ Dependency Object တွေကို Application ထဲတွင် Instantiate လုပ်ရန်မလိုအပ်ပဲ၊ လိုအပ်တဲ့အချိန်မှာ Container မှ အလိုအလျောက် Inject လုပ်ပေးနိုင်တဲ့ Service ဖြစ်ပါတယ်။ Dependency Injection ကြောင့် Dependent Component တွေထဲမှာ Dependency Object တွေကို တည်ဆောက်စရာမလိုအပ်တော့တဲ့အတွက် Component တွေအကြားမှာရှိတဲ့ Coupling ကို လျော့ချစေနိုင်ပြီး Component တွေကို လွတ်လွလပ်လပ် အသုံးပြုနိုင်အောင် ဆောင်ရွက်ပေးနိုင်ပါတယ်။ ထို့ကြောင့် Reusable ဖြစ်တဲ့ Component တွေကို ရေးသားနိုင်မှာ ဖြစ်ပါတယ်။
Inversion of Controls (IoC)
CDI ကို လေ့လာတဲ့နေရာမှာ IoC ဆိုတဲ့ Keyword ကိုလဲ မကြာမကြာ တွေ့ရှိရမှာ ဖြစ်ပါတယ်။ IoC ဆိုတာဟာ Inversion of Controls ဆိုတဲ့ စကားလုံးရဲ့အတိုကောက်ပါ။ Control တွေကို ပြောင်းပြန်လုပ်ပစ်ခြင်းလို့ အဓိပ္ပါယ်ရရှိပါတယ်။
Application တွေကို ရေးသားတဲ့အခါမှာ ပုံမှန်အားဖြင့်တော့ High Level Module (Business Class) တွေထဲမှာ Low Level Module (Technical Service API) တွေကို Management လုပ်ပြီး ရေးသားလေ့ရှိပါတယ်။ ဥပမာအားဖြင့် Database Connection တွေကို Business Class တွေက လိုအပ်လာရင် ကိုယ်တိုင် တည်ဆောက်ရပြီး အသုံးမလိုတော့တဲ့အခါမှာ ပြန်ပြီး Close လုပ်နေရပါတယ်။
Control ကို ပြောင်းပြန်လုပ်တယ်ဆိုတာက Low Level Module တွေရဲ့ Management ကို Business Module တွေက (Application ထဲကနေ) လုပ်စရာမလိုပဲ Container (Application Server) ကနေ Management လုပ်ပေးတာကို ဆိုလိုခြင်းဖြစ်ပါတယ်။ Connection တွေကို Business Module တွေထဲမှာ Control လုပ်စရာမလိုအပ်တော့တဲ့အတွက် Business Module တွေကို Environment Specific ဖြစ်တဲ့ Low Level Module တွေနဲ့ ပတ်သက်မှု့ကို လျော့ချပေးစေပါတယ်။ အဲ့ဒီအတွက် Business Module တွေကို လွတ်လွတ်လပ်လပ် ရေးသားအသုံးပြုနိုင်မှာ ဖြစ်ပါတယ်။ နမူနာအားဖြင့် မိမိရဲ့ Application ကို Development State မှာတုန်းက H2DB ကို အသုံးပြုရေးသားထားပြီး Release လုပ်တော့မှ Oracle DB ကို ပြောင်းတာတို့ လုပ်ချင်တယ်ဆိုရင်တောင် Server ပေါ်က Datasource Setup ကို ပြင်လိုက်ရုံပါပဲ။ Business Module တွေကိုပြုပြင်စရာလိုအပ်မှာ မဟုတ်ပါဘူး။
CDI ဟာ IoC ဆိုတဲ့ Concept ကို အခြေခံပြီး ရေးသားထားတဲ့ API တစ်ခုဖြစ်ပါတယ်။
Loose Coupling & Strong Typing
CDI ရဲ့ Specification ကို ရေးသားခဲ့စဉ်က ရေးသားခဲ့သူများက Loose Coupling & Strong Typing ဆိုတဲ့ အချက်ကို အဓိကထားပြီး ရေးသားခဲ့ကြပါတယ်။
Loose Coupling ဆိုတာက Component တွေကြားမှာရှိတဲ့ Coupling (ချုပ်နှောင်မှု့) ကို လျော့ချပေးခြင်းကို ဆိုလိုတာပါ။ Loose Coupling ဖြစ်တော့ ဘာဖြစ်မှာလဲ။ Component တွေက ချူပ်နှောင်မှု့ကင်းတဲ့အတွက် အဲ့ဒီ Component တွေကို ကြိုက်တဲ့နေရာမှာ လွတ်လပ်စွာ အသုံးပြုနိုင်မှာ ဖြစ်ပြီး Reusable ဖြစ်တဲ့ Component တွေကို ရေးသားနိုင်မှာ ဖြစ်ပါတယ်။
Coupling ကို ဘယ်လိုဘာသာပြန်မလဲလို့ စဉ်းစားတုန်းက သံယောဇဉ်လို့ဘာသာပြန်ခဲ့ဘူးပါတယ်။ သံယောဇဉ်များလေလေ လွတ်လပ်မှု့ဆုံးရှုံးလေဖြစ်ပါမယ်။ အဲ့ဒီအတွက် ဟိုဟာလုပ်ချင်လဲ မလုပ်နိုင် ဒီဟာ လုပ်ချင်လဲ မလုပ်နိုင်ဖြစ်ပါမယ်။
အဲ့ဒီလိုပဲ Coupling များတဲ့ Component တွေဟာ လွတ်လပ်မှု့ရှိမှာမဟုတ်ပါဘူး။ အဲ့ဒီ Component ကို သုံးချင်ရင် အဲ့ဒီ Component တွေနဲ့ ပတ်သက်နေတဲ့ Component မရှိပဲ သုံးလို့မရဘူး တို့ဖြစ်လာပါမယ်။ ဟိုနေရာလဲ သုံးမရ ဒီနေရာလဲ သုံးမရဖြစ်လာပြီး သုံးရခက်တဲ့ Component ဖြစ်လာမှာ ဖြစ်ပါတယ်။
CDI ရဲ့ ဘယ် Feature တွေက Loose Coupling ကို တိုးတက်အောင်လုပ်ပေးနိုင်တာလဲ။
Dependency Injection(DI) ဆိုတာ CDI ရဲ့ အဓိက Feature တစ်ခုဖြစ်ပါတယ်။ DI ကြောင့် Java EE ပတ်ဝန်းကျင်မှာ ရေးသားနေတဲ့ Object တွေကို သူတို့ရဲ့ Dependency တွေ (သူတို့အသုံးပြုနေတဲ့ Objectတွေ) နဲ့ Decouple လုပ်ပေးနိုင်ပါတယ်။
တဖန် Contextual Lifecycle Management ဆိုတဲ့ Feature ကြောင့် Object တွေကို Well Define ဖြစ်တဲ့ Scope တွေ အတွင်းမှာ အသုံးပြုနိုင်အောင် ဆောင်ရွက်ပေးနိုင်ပြီး Lifecycle ကို Manage လုပ်ရတဲ့ Code တွေနဲ့ Decouple ဖြစ်အောင် ဆောင်ရွက်ပေးနိုင်ပါတယ်။ ထို့အပြင် CDI ရဲ့ Scope တွေကို Java EE ရဲ့ Container တွေဖြစ်ကြတဲ့ Web Container ရော EJB Container မှာပါ အသုံးပြုနိုင်ပါတယ်။ ဒါ့ကြောင့် CDI Scope တွေကို Presentation Layer မှာကော Business Layer မှာကော Persistance Layer မှာပါ အသုံးပြုနိုင်ပါတယ်။ ရလဒ်အနေနဲ့ Coponent တွေကို Manageလုပ်တဲ့ Container က မတူပေမဲ့ သူတို့တွေအားလုံးကို CDI ကို အသုံးပြုပြီး Layer တစ်ခုထဲမှာ အလုပ်လုပ်နေသလို အသုံးပြုနိုင်မှာ ဖြစ်ပါတယ်။
Interceptor ဆိုတာက Business Logic Code တွေနဲ့ နည်းပညာအရလိုအပ်တဲ့ Technological Concern တွေကို Decouple လုပ်ပေးနိုင်ပါတယ်။ ဥပမာအားဖြင့် Database ထဲကို Record တစ်ကြောင်း Insert လုပ်ချင်တယ်။ ဒါပေမဲ့ ရေးသားမယ်ဆိုင် Insert မလုပ်ခင် Trasaction ကို Begin လုပ်ပေးရမယ်။ ပြီးရင် Commit လုပ်မယ်။ Error ဖြစ်ရင် Roll Back လုပ်မယ်။ ဒါတွေကို နေရာတိုင်းမှာ ရေးသားနေရမှာပါ။ အဲ့ဒီလို Technical အရလိုအပ်တဲ့ Code တွေကို Interceptor ထဲမှာ ရေးသားထားပြီး Business Method တိုင်းမှာ လုပ်ဆောင်စေနိုင်ရန် ရေးသားနိုင်ပါတယ်။ ဒါ့ကြောင့် Business Method တွေထဲမှာ လိုအပ်တဲ့ Code တွေသာ ရေးသားရန်လိုအပ်တဲ့အတွက် Code တွေရဲ့ Readablity ကိုလဲ တိုးတက်စေနိုင်ပြီး Maintainablity ကိုလဲ မြင့်မားစေနိုင်ပါတယ်။ တဖန် Developer တွေဟာ မိမိရဲ့ Business Logic ကိုသာ အာရုံစိုက်စရာ လိုအပ်တော့တဲ့အတွက် အမှား တွေကိုလဲ လျော့ချစေနိုင်ပါတယ်။ Interceptor ဆိုတာက Aspect Oriented Programming (AOP) နဲ့ တူညီတဲ့ ရလဒ်တွေကို ဆောင်ရွက်ပေးနိုင်ပါတယ်။
Decorator ဆိုတာက ထင်ရှားတဲ့ Design Pattern တစ်ခုဖြစ်ပြီး CDI မှာလဲ အသုံးပြုနိုင်အောင် ပြင်ဆင်ထားပါတယ်။ Decorator ဆိုတာက မူရင်း Service ရဲ့ရလဒ်ကို အမျိုးမျိုး Decorate လုပ်ရင်း မတူညီတဲ့ ရလဒ်တွေကို ရရှိစေနိုင်တဲ့ Design Pattern တစ်မျိုးဖြစ်ပါတယ်။ မူလ Service ရဲ့ ရလဒ်နဲ့ မတူညီတဲ့ ရလဒ် အသစ်တစ်မျိုးရရှိလိုပါက Decorate လုပ်ချင်းအားဖြင့် မတူညီတဲ့ Service အသစ်တွေကို ဖန်တီးပေးနိုင်မှာ ဖြစ်ပါတယ်။ ကျွန်တော်တို့ပတ်ဝန်းကျင်မှာလဲ Decorator Pattern ကို သုံးနေတာကို နေ့စဉ်တွေ့မြင်နိုင်ပါတယ်။ နမူနာအားဖြင့် လဘက်ရည်ဆိုင်တစ်ဆိုင်ဆိုကြပါဆို့။ အကျရည်ရှိတယ် ဆိုရင် ချို့ကျတို့ ချိုစိမ့်တို့ ချိုပေါ့ကျတို့ နို့ဆီ သကြားတို့ကို ပုံစံအမျိုးမျိုးနဲ့ Decorate လုပ်ရင်း Service အမျိုးမျိုး ကို ဆောင်ရွက်ပေးနိုင်နေခြင်းဖြစ်ပါတယ်။
Event ဆိုတာကလဲ CDI ရဲ့ ထူးခြားတဲ့ Feature တစ်ခုရှိပါတယ်။ Event ဆိုတာကတော့ Observable Design Pattern ကို အခြေခံထားတဲ့ Feature ဖြစ်ပါတယ်။ Java EE Application ထဲမှာရှိတဲ့ ကြိုက်တဲ့ Component က Event Producer ဖြစ်နိုင်ပြီး၊ ကြိုက်တဲ့ Component က Event Consumer ဖြစ်နိုင်ပါတယ်။ Event Producer က Event တစ်ခုကို Fire လုပ်လိုက်တာနဲ့ သတ်မှတ်ထားတဲ့ Event Consumer တွေက အလိုအလျောက် ထပြီး အလုပ်လုပ်ပေးမှာ ဖြစ်ပါတယ်။ CDI ရဲ့ Event Producer နဲ့ Event Consumer တွေဟာ Compile Time မှာတောင် အချင်းချင်း သိနေစရာမလိုအပ်ပါဘူး။
CDI ဟာ Dependency Inject တွေကို ဆောင်ရွက်တဲ့ နေရာမှာ Type Safe ဖြစ်အောင် String တွေနဲ့ရေးသားရတဲ့ နည်းအစား Qualifier ဆိုတဲ့ Annotation ကို အသုံးပြုနိုင်အောင် ဆောင်ရွက်ထားပါတယ်။ ဒါ့ကြောင့် အမည်တူပေးပြီး Type တွေကို မှားပြီး Inject မလုပ်ဖြစ်အောင် ဆောင်ရွက်ပေးနိုင်ပါတယ်။
Brief History of CDI
What new in CDI 1.1
- Managed Bean တွေရဲ့ ပြင်ပမှ CDI class တွေမှတဆင့် CDI facilities တွေကို ဆက်သွယ် အသုံးပြုလာနိုင်ပါတယ်။
- Interceptors, decorators, and alternatives တွေရဲ့ Priority ကို @Priority ကို အသုံးပြုပြီး ခွဲခြားသတ်မှတ်နိုင်ပါတယ်။
- Type တွေ၊ ဒါမှမဟုတ် package တွေမှာ @Vetoed annotation ကို ရေးသားပြီး CDI မှနေ Bean တစ်ခု အဖြစ်မစဉ်းစားအောင် တားစီးနိုင်ပါတယ်။
- @New qualifier ကို ရပ်နားပြီး၊ @Dependent scoped beans ကိုအသစ်Inject လုပ်နိုင်ပါတယ်။
- @WithAnnotations အားအသုံးပြုပြီး အသုံးပြုနိုင်တဲ့ Type တွေကို Filter လုပ်နိုင်လာပါတယ်။
ဆက်ပါဦးမည်။
မင်းလွင်
No comments:
Post a Comment