မင်္ဂလာပါ!

လှိုက်လှဲစွာကြိုဆိုပါသည်။ ယခု ပထမဆုံးအကြိမ် ရောက်ဖူးခြင်းဖြစ်ပါသလား? ဝင်ရောက် ဆွေးနွေး မေးမြန်းလိုပါလျှင် အောက်တွင်ဖော်ပြထားသော button များမှတဆင့် ဝင်ရောက် ဆွေးနွေးနိုင်သကဲ့သို့ အဖွဲ့ဝင်အသစ်အနေဖြင့်လည်း လျှောက်ထားနိုင်ပါတယ်။

MYSTERY ZILLION တွင် English သို့မဟုတ် Unicode ဖြင့်သာ အသုံးပြုခွင့်ရှိသည်။ ဇော်ဂျီ ၊ ဧရာ စသည်တို့ကို အသုံးပြုခွင့် မရှိ။ Unicode fonts များမှာ Mon3,Yunghkio, Myanamr3 စသည်များ အသုံးပြုနိုင်သည်။ Unicode Guide ကို ဒီမှာ Download ချပါ။ Zawgyi to Unicode Converter
Don't share ebook or software if nobody request. You can find free book websites on here. We are welcome for discussion or asking question instead.

What is Spring Framework ?

edited November 2014 in Java

Spring သည် enterprise applications များအတွက် အလွန်ကောင်းမွန်သော developing framework တစ်ခုဖြစ်ပြီး သေးငယ်သော (light-weight) frameworkတစ်ခုလည်း ဖြစ်သည်။
Spring သည် အလွန်ရိုးရှင်းပြီး များပြားကြွယ်ဝသော စွမ်းဆောင်ရည်များဖြင့် အမျိုးမျိုးသော frameworkများ ၊ နည်းပညာများ ၊ application များ၏ service တို.ဖြင့်လည်း ပူးပေါင်းဆောင်ရွက်နိုင်သည်။ အဓိက Spring framework ကိုသုံးရခြင်း၏ရည်ရွယ်ချက်မှာ code များကို တတ်နိုင်သမျှ ရိုးရှင်းလွယ်ကူအောင် ထိန်းသိမ်းလိုခြင်းဖြစ်သည်။ ထို့အပြင် enterprise application များအား မှီခိုမှု ၊ ဆက်နွယ်မှုများကင်းသည်. Java beans များဖြင့် develop လုပ်နိုင်စေရန်အထောက်အပံ့ပေးသည်။ ထိုအချက်ကြောင့်ပင် Spring framework အား Plain Old Java Object(POJO) framework ဟုခေါ်နိုင်သေးသည်။ Spring သည် လွတ်လပ်စွာ အသုံးပြုနိုင်သော ၊ အခကြေးငွေပေးစရာမလိုသော(open-source) framework တစ်ခုလည်းဖြစ်သည်။
Spring ကို အကျဉ်းအားဖြင့် နှစ်မျိုးခွဲခြားနိုင်သည်။

၁ ။ Container

Spring အား ပေါ့ပါးသော ၊ size သေးငယ်သော ၊ နေရာသိပ်မယူသော ၊ installation လုပ်စရာမလိုသော ၊ configure ချစရာမလိုသော ၊ ဖွင့်ရန် ပိတ်ရန် မလိုအပ်သော သယ်ယူပို.ဆောင်ပေးသောအရာတစ်ခုအဖြစ် (light-weight container) လည်းသတ်မှတ်နိုင်သည်။
အမှန်အားဖြင့် Spring သည် မိမိ project ၏ classpath တွင် အလွယ်တကူ ထည်.သွင်းအသုံးပြုနိုင်သော ရိုးရှင်းသည်. Jar file များ စုစည်းထားသော အရာတစ်ခုသာဖြစ်ပါသည်။

၂ ။ Framework

Spring framework အား Application များအတွက် အသုံးဝင်သော class များ ၊ method များ ၊ interface များ ၊ annotations များ ၊ XML tag များ အများအပြားစုဝေးထားသည်. API တစ်ခုအဖြစ်လည်းသတ်မှတ်နိုင်သည်။


Spring က JDBC အတွက် လည်းအများကြီး support လုပ်တယ် ။ DataBase Operation တွေအတွက် exception Handling ၊ Queries Execution ၊ Statements များရေးသားခြင်း ၊ connection ယူတာတွေကို လွယ်ကူအောင် ပြုလုပ်ပေးတယ်။ JDBC operation တွေအတွက် အသေးစိတ် စီမံ ၊ ဂရုစိုက် ၊ manage လုပ်ဖို. အဆင်သင့် ပါဝင်တဲ့ class တွေလည်းသူ.မှာရှိတယ်။

Hibernate , Toplink , iBatis တို.လို Object Relational Mapping (ORM) တွေ အတွက် အရမ်းလွယ်ကူတဲ့ classes တွေလည်းရှိတယ်။

နောက်တစ်ခု Spring ကို အဓိက သုံးရခြင်း အကြောင်းက များပြား ကျယ်ပြန်.တဲ့ AOP Service တွေကို support လုပ်လို. ။ AOP (Aspect Oriented Programming ) ဆိုတာ အကျဉ်းအားဖြင့် ကြားဖြတ်လုပ်ဆောင် မှုများကို ဦးတည်သော လို.ပြောလို.ရတယ် ။ 3C (Cross Cutting Concern) ပေါ့ ။ ရှိပြီးသား Design တွေ ၊ method တွေကို မပြောင်းလဲပဲ တစ်ခြား အလုပ်တွေ ကြားညှပ်လုပ်စေတာ ၊
method တွေကို သွယ်ဝိုက်သောနည်းဖြင့် modify လုပ်တာ (တိုက်ရိုက်မဟုတ်ပဲ) ၊ တစ်ခြား လုပ်ဆောင်စရာရှိတာတွေကို method တစ်ခုလုပ်ဆောင်တဲ့ အခါမှာ တစ်ခါတည်း လုပ်ဆောင်စေတာ ၊ ပြောရရင် ရှိပြီးသား method တွေကို တစ်ခြား အပို အလုပ်တွေ ထပ်ပြီးလုပ်ကိုင်စေတာ ၊ ဥပမာ .... log ရိုက်တာ , security စစ်တာ , transaction management လုပ်တာ ... အဲတာမျိုးကို AOP လို.ခေါ်တယ်။

Spring ရဲ. Core package မှာ ဆိုရင် framework ရဲ. အခြေခံ အကျ ဆုံးဖြစ်တဲ့ IOC (Inversion of Control) နဲ. Dependecy Injection features တွေ support လုပ်တယ်။ အခြေခံအားဖြင့် BeanFactory ပေါ့။ BeanFactory က တို. program logic တွေမှာပါတဲ့ dependencies တွေ ၊ configuration ချတာတွေကို အချင်းချင်း မှီခိုမှု ကင်းမဲ့စေတယ်။ နောက်ပြီး programmatic singletons
လုပ်စရာမလိုအောင်လုပ်ပေးတယ်။ programmatic singletons လုပ်တယ်ဆိုတာ ..... Class တစ်ခုရဲ. instance ကို new နဲ. ဆောက်လို.မရအောင် ကိုယ့်ဘာသာကို manually လိုက်ရေးရတာတွေ ကို ဆိုလိုတာ။ Singletons Object ဆိုတာ memory ပေါ်မှာ တစ်ခါပဲ ဆောက်ပြီးရင် ...... အကြိမ်ကြိမ်ခေါ်သုံးလို.ရသွားပြီ ။ new နဲ. ဆောက်တိုင်းသာဆို memory ပေါ်မှာ Object တွေရှိစေတာကိုတော့
prototype ပုံစံလို.ခေါ်တယ်။

Spring 3.0 ကနေ စပြီး OXM ကို support လုပ်လာခဲ့တယ်။ အစကတုန်းက OXM (Object-XML Mapping) က Spring ရဲ. core framwork ထဲမှာ မရှိသေးဘူး။ OXM ဆိုတာ marshalling(Object to xml) , unmarshalling(xml to Object) လုပ်တဲ့ framework ကိုပြောတာ။ တစ်ခြား OXM framework တွေရှိသေးတယ် (Caster , Xstream , JiBX ,JAXB = Java API for XML Binding, XMLMeabs )။ Spring 3 ကနေစပြီး ဘယ် OXM framework နဲ.မဆို marshalling and unmarshalling လုပ်ဖို. ထောက်ပံ့ပေးတယ်။

Spring က IOC (Inversion of Control) ကို support လုပ်တယ်။ DI (Depency Injection) ဆိုတာ IOC ရဲ. sub ( အခွဲ ) ပဲ ။ IOC မှာ DI တစ်ခုတည်း ပါတာမဟုတ်ဘူး ။ တစ်ခြား IOC techn: တွေရှိသေးတယ်။ ဒါပေမယ့် အဓိက သုံးကြတာကတော့ DI ပေါ့ ။ အဲတာကို DI နဲ. IOC အတူတူပဲ လို.တော့သွားမရောနဲ.။
IOC က DI ထက်ပိုကျယ်ပြန်.ပါသေးတယ် ။ parent class ပေါ့ အကြမ်းဖျင်း။ DI ဆိုတာ Object တွေ အချင်းချင်း မှီခိုမှု နည်းပါးလာအောင် လုပ်ဆောင်ပေးတဲ့ technology ကိုပြောတာပါ။ အဓိပ္ပာယ် အနေနဲ. Class X ထဲ မှာ Class Y ရဲ. instance ရှိတယ် ဆိုပါဆို. ။
အဲတာဆို Class X ဟာ Class Y အပေါ်မှာ မှီခိုမှု ရှိသွားပြီ။ အဲတာကို Depency လို.ခေါ်တယ်။ အဲတော့ Class X ရဲ. method တွေထဲမှာ Class Y ရဲ. instance နဲ. execute လုပ်မယ်ဆိုရင် Class Y ရဲ. instance ကို ဆောက်လုပ်ပြီးမှ အသုံးပြု လို.ရမယ် ။ အဲတာကို ကိုယ်တိုင် instance ဆောက်တဲ့ code တွေရေးစရာမလိုပဲ Spring Container ကတစ်ဆင့်
ဆောက်လုပ် ရယူ ခြင်းကို Injection (ထိုးသွင်းခြင်း) လို.ခေါ်တယ်။

Spring ကို အသုံးပြုခြင်းအားဖြင့်ရရှိသော အကျိုးကျေးဇူးများ


၁ ။ Developer တွေကို POJOs( Plain Old Java Objects ) တွေပဲ အသုံးပြုပြီး enterprise application တွေဖန်တီးလုပ်ဆောင်နိုင်စေတယ်။ POJOs တွေကိုပဲ အသုံးပြုခြင်းအားဖြင့်ရရှိတဲ့ အကျိုးကျေးဇူးကတော့ EJB Container product တွေကို Application Server အနေနဲ. သုံးစရာမလိုတော့ဘူး ။
(စကားချပ် - EJB (Enterprise Java Bean ) နဲ. EJP container product တွေ အကြောင်း ရေးတာမဟုတ်လို. နည်းနည်းမှတောင် ဖော်ပြပေးခြင်း မလုပ်တော့ဘူး ။ သိချင်ရင် try in Google ။ ဒါမှ မဟုတ် နောက်မှ modify လုပ်) ကိုယ့်ဘာသာကိုယ် မြန်လည်းမြန် ၊ ကောင်းလည်းကောင်းတဲ့ Tomcat တို.ဘာတို.သုံးလည်းရတယ် ။

၂ ။ Spring က အလွယ်တကူ ပြောင်းလဲ လုပ်ယူလို.ရတဲ့ ပုံစံမျိုးနဲ. ဖွဲ.စည်းထားတယ်။ သူ.မှာ ရှိတဲ့ package တွေ ၊ classes တွေ နဲ.တင်အားလုံး ပြည်.စုံ ပါတယ်။ မင်းဘာလိုချင်လဲ ဆိုတာကိုပဲ သိအောင်လုပ်ပါ။ REST ကိုတောင် ထည်.စဉ်းစားစရာမလိုပါဘူး ။(Spring 4 မှာတော့ rest ကို ကောင်းကောင်း support လုပ်လာပါတယ်။ REST ကိုရောသိလား ? try in Google or နောက်မှ modify )

၃ ။ Spring နဲ. ရေးထားတဲ့ application တွေဟာ testing လုပ်ရတာ အရမ်းရိုးရှင်း လွယ်ကူတယ်။

၄ ။ Spring ရဲ. Web framework ကလည်း သေသေချာချာ ဖွဲ.စည်းထားတဲ့ MVC (Model View Controller) framework တစ်ခုဖြစ်တယ်။

၅ ။ Spring က technology-specific exceptions (JDBC, Hibernate, or JDO အစရှိသဖြင့် လူသိများ လူသုံးများတဲ့ framework တွေ ၊ Technology တွေက ပစ်တဲ့ exception တွေ) ကိုလည်း အဆင်ပြေအောင် translate လုပ်ပေးနိုင်တယ်။

၆ ။ Spring ရဲ. IOC container က EJB ရဲ. Container တွေနဲ. ယှဉ်လိုက်ရင် အရမ်းကို Light-weight ဖြစ်တယ်။ အဲတော့ CPU နိမ့်တဲ့ Computer တို. ၊ Memory နိမ့်တဲ့ Computer တွေမှာ Develop လုပ် ၊ Deploy လုပ်ရတဲ့ Programmer တွေအတွက် ဆိုရင်လည်း အဆင်ပြေစေတယ်။

၇ ။ Spring ရဲ. Transaction Management API ဟာ Local Transaction ( Single DataBase တစ်ခုတည်းကိုပဲသုံးတာမျိုး ) ပဲ ဖြစ်ဖြစ် Global Transaction (Web ပေါ်ကလိုမျိုး ၊ DataBase အမြောက်အမြားကိုချိတ်ဆက်သုံးတာမျိုး ) ပဲဖြစ်ဖြစ် အဆင်ပြေအောင် ထောက်ပံ့ပေးတယ်။

DI (Dependencie Injection) အတွက် လက်တွေ.ကျတဲ့ ဥပမာ

ပထမဖြစ်စဉ်

တို.ရုံးကလူတွေ မန္တလေးကို ဘုရားဖူး သွားဖို. တိုင်ပင်ကြတယ် ။ အားလုံးပဲ ငါတို. အောင်မင်ဂလာ ကားဝင်းက “မန္တလာသူ” ကားဂိတ်မှာလက်မှတ်ဖြတ်ပြီး သွားကြမယ် လို. စီစဉ်ထားကြတယ် ။ အဲတော့ ကြိုတင်ပြီး ကားဂိတ် ကို ဖုန်းဆက် ။ မှတ်ပုံတင် နံပါတ်ပြော ဘယ်နေ. ဘယ်အချိန်ကား နဲ. လူဘယ်နှစ်ယောက်လိုက်မယ် ကြိုတင်ပြီး booking ယူ ။ ကားဂိတ်ကို ဘယ်လိုသွားကြမယ် စီစဉ် ။ (ဥပမာ - အသိမိတ်ဆွေကား လိုက်ပို.မယ် စသည်ဖြင့်)
အဲဒီလို စီစဉ်ထားပြီးမှ အကြောင်းတစ်ခုတစ်ခု ကြောင့် အစီအစဉ်ပြောင်းရမယ်ဆိုပါစို.။ (ဟာ…. မန္တလာသူကား က အဲကွန်းမကောင်းဘူး ၊ ခဏခဏ လမ်းမှပျက်တယ် ၊ လမ်းမှာကြာတယ် ၊ ဆက်ဆံမှုမကောင်းဘူး ။ အဲတာကြောင့် “တက်လမ်း” ကားဂိတ်ကနေသွားကြမယ် ဆိုပါစို. )

၁ ။ ပထမ booking လုပ်ထားတဲ့ ကားဂိတ်ကို မလိုက်ဖြစ်တော့ပါဘူး ဆိုပြီး ပြန်အကြောင်းကြားရမယ်။

၂ ။ နောက် အစီအစဉ်အတိုင်းသွားဖို.အတွက်ပြန်ပြင်ဆင်ရမယ်။ (“တက်လမ်း” ကားဂိတ်ကိုဖုန်းပြန်ဆက်ပြီး ဘယ်အချိန် ထွက်မယ့် ကားနဲ.လိုက်ပါမယ် ။ မှတ်ပုံတင် နံပါတ်က ဘယ်လောက် စသည်ဖြင့် information တွေပြန်ပေးရမယ်။)

၃ ။ ကားဂိတ်ကိုသွားဖို. အစီအစဉ် ပြန်ပြောင်းရမယ် (ကားနဲ.လိုက်ပို.မယ့် အသိမိတ်ဆွေ ကို ဖုန်းပြန်ဆက် ပြီး “တက်လမ်း” ကားဂိတ်ကိုလိုက်ပို.ပါ အရင် ပြောထားတဲ့ ကားဂိတ်ကို မဟုတ်တော့တဲ့အကြောင်း ။ အချိန် ကလည်း ဘယ်အချိန်ဖြစ်သွားပါပြီ စသည်ဖြင့်)
အဲဒီလိုမျိုးသာ အခြေအနေ အပြောင်းအလဲ ဖြစ်ခဲ့ရင် ကိုယ်တိုင်ရော ၊ ကိုယ့်လုပ်ဖော်ကိုင်ဖက်တွေ ၊ ဘုရားဖူးလိုက်မယ့်လူတွေအားလုံး ကိုယ့်ရဲ. အရင် စီစဉ်ထားတဲ့ အခြေအနေတွေအကုန်လုံးပြန်ပြီး ညှိရရော။

အဲလိုပြန်ပြီးညှိရတာဟာ အချိန်တွေကုန် ၊ အလုပ်ရှုပ်မှုတွေဖြစ်စေတယ်။

ဒုတိယဖြစ်စဉ်

ငါတို.မန္တလေးကို ဘုရားဖူးသွားကြမယ် ။ ခရီသွားဖို.ကိစ္စကို စီစဉ်ပေးမယ့်လူတစ်ယောက်ရှိတယ်ဆိုပါစို. (ဥပမာ - အောင်မင်္ဂလာကားဝင်းထဲမှာ ကျွမ်းကျင်လည်ပတ်တဲ့လူတစ်ယောက်) သူ.ကို ဘယ်ကားဂိတ်ကနေသွားချင်ပါတယ် ၊ လူဘယ်နှစ်ယောက် ၊ ဘယ်အချိန် ၊ မှတ်ပုံတင်နံပါတ်က ဘယ်လောက် စသည်ဖြင့် information တွေပေးလိုက်မယ်။ တို.တွေကို ကားဂိတ်ဆီသွားဖို. ကားတစ်စီးလောက် ဘယ်ကို ဘယ်အချိန်လွှတ်ပေးပါ စသည်ဖြင့် ပြောထားလိုက်မယ်။
အဲဒီ့မှာ မန္တလာသူ ကားဂိတ်ကနေမသွားချင်တော့ပဲ တက်လမ်း ကားဂိတ်ကနေ သွားချင်တယ် ဆိုပါစို.။ စီစဉ်တဲ့ လူကို ပဲ ဘယ်ကားဂိတ်ကနေပဲ သွားပါတော့မယ်လို.ပြောလိုက်ရုံပဲ။

၁ ။ ကားဂိတ်နဲ. ဆက်သွယ်ပြီး ပြန်ပြန်ပြောစရာမလိုတော့ဘူး။

၂ ။ နောက်အစီ အစဉ် အတွက်ရယ်လို.ထူးထူးထွေထွေပြန်ပြောင်းစရာမလိုတော့ဘူး ။

၃ ။ နောက်ကားဂိတ်အတွက် ကိုယ့်ရဲ. Information တွေပြန်ပေးပြီး booking အလုပ်တွေပြန်လုပ်စရာမလိုဘူး။

အားလုံးကို စီစဉ်ပေးမယ့်လူကပဲ အကုန်လုပ်ပေးလိမ့်မယ်။ အဲတော့ တို.တွေတစ်ယောက်ချင်းစီအတွက် ဘာမှလည်း အလုပ်မရှုပ်တော့ဘူး ။
ဒါကသေးငယ်တဲ့ဖြစ်စဉ် တစ်ခု တည်းပါ ။ အပေါ်က လိုမျိုးသာ ကြီးမား တဲ့လုပ်ငန်းဖြစ်စဉ် ကြီးတွေမှာ အပြောင်းအလဲ ဖြစ်ခဲ့မယ် ဆိုရင် ? အကုန် လိုက်ပြောင်းနေ ရမယ်ဆိုရင် ? ပုံပေါ်ကြည်.လိုက်ပါ။

Tagged:
Sign In or Register to comment.