အရှိန်မြှင့်ရောင်ပြန်ဟပ်ခြင်းအကြောင်း မအောင်မြင်သော ဆောင်းပါး

ဆောင်းပါးခေါင်းစဉ်ကို ချက်ချင်းရှင်းပြမယ်။ မူလအစီအစဉ်သည် ရိုးရှင်းသော်လည်း လက်တွေ့ကျသော ဥပမာကို အသုံးပြု၍ ရောင်ပြန်ဟပ်မှုကို အရှိန်မြှင့်ရန် ကောင်းသော၊ ယုံကြည်စိတ်ချရသော အကြံဉာဏ်များကို ပေးဆောင်ရန်ဖြစ်သည်၊ သို့သော် စံညွှန်းအမှတ်အသားပြုစဉ်တွင် ရောင်ပြန်ဟပ်မှုမှာ ထင်ထားသလောက် မနှေးတော့ဘဲ LINQ သည် ကျွန်ုပ်၏အိပ်မက်ဆိုးများထက် နှေးကွေးနေပါသည်။ ဒါပေမယ့် နောက်ဆုံးမှာတော့ တိုင်းတာမှုမှာ ကျွန်တော် မှားသွားခဲ့တယ်... ဒီဘဝဇာတ်ကြောင်းရဲ့ အသေးစိတ်အချက်အလတ်တွေကို ဖြတ်တောက်ပြီး မှတ်ချက်တွေမှာ ရေးထားပါတယ်။ ဥပမာက အတော်လေးကို သာမန်ဖြစ်ရိုးဖြစ်စဉ်တစ်ခုဖြစ်ပြီး လုပ်ငန်းတစ်ခုတွင် အများအားဖြင့်လုပ်ဆောင်သကဲ့သို့ နိယာမအရ အကောင်အထည်ဖော်ခြင်းဖြစ်သောကြောင့်၊ ကျွန်ုပ်၏ထင်မြင်ချက်အတိုင်း၊ ဘဝသရုပ်ပြခြင်း- ဆောင်းပါး၏ အဓိကအကြောင်းအရာ၏ အရှိန်အဟုန်အပေါ် သက်ရောက်မှုမှာ အလွန်စိတ်ဝင်စားစရာကောင်းပါသည်။ ပြင်ပယုတ္တိဗေဒကြောင့် သတိမထားမိပါ- Moq၊ Autofac၊ EF Core နှင့် အခြား "ကြိုးများ"။

ဤဆောင်းပါး၏ စိတ်ကူးဖြင့် စတင်အလုပ်လုပ်ခဲ့သည်၊ Reflection က ဘာကြောင့်နှေးတာလဲ။

သင်တွေ့မြင်ရသည့်အတိုင်း၊ စာရေးသူသည် အပလီကေးရှင်းကို အလွန်အရှိန်မြှင့်ရန် နည်းလမ်းကောင်းအဖြစ် ရောင်ပြန်ဟပ်မှုအမျိုးအစားကို တိုက်ရိုက်ခေါ်ဆိုမည့်အစား စုစည်းထားသော ကိုယ်စားလှယ်များကို အသုံးပြုရန် အကြံပြုထားသည်။ ဟုတ်ပါတယ်၊ IL ဓာတ်ငွေ့ထုတ်လွှတ်မှု ရှိပါတယ်၊ ဒါပေမယ့် အမှားအယွင်းတွေနဲ့ ပြည့်နှက်နေတဲ့ အလုပ်တစ်ခုကို လုပ်ဆောင်ဖို့ ဒါက လုပ်သားအများဆုံး နည်းလမ်းဖြစ်လို့ အဲဒါကို ရှောင်ရှားချင်ပါတယ်။

ရောင်ပြန်ဟပ်မှုအရှိန်နှင့် ပတ်သက်၍ ကျွန်ုပ်အမြဲတမ်း အလားတူထင်မြင်ယူဆထားသည်ဟု ယူဆပါက စာရေးသူ၏ ကောက်ချက်ကို မေးခွန်းထုတ်ရန် အထူးမရည်ရွယ်ပါ။

လုပ်ငန်းမှာ နုံအတဲ့ ရောင်ပြန်ဟပ်မှုကို မကြာခဏ ကြုံရတယ်။ အမျိုးအစားကို ယူသည်။ ပိုင်ဆိုင်မှုနှင့်ပတ်သက်သည့် အချက်အလက်များကို ရယူထားသည်။ SetValue နည်းလမ်းကို ခေါ်ပြီး လူတိုင်း ဝမ်းမြောက်ကြသည်။ ပစ်မှတ်နယ်ပယ်သို့ ရောက်ရှိလာသော တန်ဖိုးသည် လူတိုင်း ပျော်ရွှင်နေကြသည်။ အလွန်ထက်မြက်သူများ - သက်ကြီးရွယ်အိုများနှင့် အဖွဲ့ခေါင်းဆောင်များ - အမျိုးအစားတစ်ခုမှ တစ်ခုသို့ ပုံဖော်ထားသည့် "universal" mappers သည် နုံချာသော အကောင်အထည်ဖော်မှုအပေါ် အခြေခံ၍ ၎င်းတို့၏ နောက်ဆက်တွဲများကို ကန့်ကွက်ရန် ရေးသားပါ။ အနှစ်သာရမှာ အများအားဖြင့် ဤအရာဖြစ်သည်- ကျွန်ုပ်တို့သည် အကွက်အားလုံးကိုယူ၍ ဂုဏ်သတ္တိများအားလုံးကို ယူကာ ၎င်းတို့အပေါ် ထပ်လောင်းပါ- အမျိုးအစားအဖွဲ့ဝင်များ၏ အမည်များနှင့် ကိုက်ညီပါက၊ ကျွန်ုပ်တို့သည် SetValue ကို လုပ်ဆောင်ပါသည်။ ကျွန်ုပ်တို့သည် အမျိုးအစားများထဲမှ အချို့သောပိုင်ဆိုင်မှုများကို ရှာမတွေ့သည့် အမှားများကြောင့် ခြွင်းချက်များကို အခါအားလျော်စွာ ဖမ်းမိသော်လည်း ဤနေရာတွင်ပင် စွမ်းဆောင်ရည်ကို ပိုမိုကောင်းမွန်စေမည့် နည်းလမ်းတစ်ခုရှိပါသည်။ ကြိုးစား/ဖမ်း။

အရင်က ပါလာတဲ့ စက်တွေ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတဲ့ အချက်အလက်ကို အပြည့်အ၀ လက်နက်မပါဘဲ လူတွေက parser နဲ့ mappers တွေကို ပြန်လည်ဆန်းသစ်ထားတာ တွေ့ဖူးတယ်။ ဗျူဟာများနောက်ကွယ်တွင်၊ အင်တာဖေ့စ်နောက်ကွယ်တွင်၊ ထိုးဆေးများ၏နောက်ကွယ်တွင် ၎င်းတို့၏နုံအသောအကောင်အထည်ဖော်မှုများကို လူများက ဖုံးကွယ်ထားသည်ကို မြင်ဖူးသည်၊ ၎င်းသည် နောက်ဆက်တွဲ bacchanalia ကို အကြောင်းပြချက်ပေးမည်ဆိုပါက၊ အဲဒီလို သဘောပေါက်လာတဲ့အခါ နှာခေါင်းကို လှည့်ကြည့်လိုက်တယ်။ အမှန်တော့၊ ကျွန်ုပ်သည် အမှန်တကယ် စွမ်းဆောင်နိုင်မှု ယိုစိမ့်မှုကို မတိုင်းတာခဲ့ဘဲ ဖြစ်နိုင်ပါက၊ ကျွန်ုပ်သည် ၎င်းကို လက်လှမ်းမီနိုင်လျှင် ပိုမို၍ "အကောင်းဆုံး" တစ်ခုသို့ ပြောင်းလဲလိုက်ပါသည်။ ထို့ကြောင့်၊ အောက်တွင်ဖော်ပြထားသော ပထမအကြိမ် တိုင်းတာမှုများသည် ကျွန်ုပ်အား အကြီးအကျယ် စိတ်ရှုပ်ထွေးစေပါသည်။

Richter သို့မဟုတ် အခြားသော အယူဝါဒပညာရှင်များကို ဖတ်ရှုခြင်း ၊ ကုဒ်တွင် ရောင်ပြန်ဟပ်မှုသည် အပလီကေးရှင်း၏ စွမ်းဆောင်ရည်အပေါ် အလွန်အမင်း အပျက်သဘောဆောင်သည့် ဖြစ်စဉ်တစ်ခုဖြစ်ကြောင်း လုံး၀ တရားမျှတသော ထုတ်ပြန်ချက်တစ်ခုကို တွေ့ကြပြီထင်ပါတယ်။

ရောင်ပြန်ဟပ်မှုခေါ်ဆိုခြင်းသည် CLR အား ၎င်းတို့လိုအပ်သည့်အရာကို ရှာဖွေရန်၊ ၎င်းတို့၏ မက်တာဒေတာကို ဆွဲထုတ်ကာ ၎င်းတို့ကို ခွဲခြမ်းစိတ်ဖြာရန် စသည်ဖြင့် စုစည်းမှုများပြုလုပ်ရန် တွန်းအားပေးသည်။ ထို့အပြင်၊ ဆင့်ကဲဖြတ်သွားစဉ် ရောင်ပြန်ဟပ်မှုသည် မှတ်ဉာဏ်ပမာဏများစွာကို ခွဲဝေပေးသည်။ ကျွန်ုပ်တို့သည် မမ်မိုရီကို အသုံးပြုနေသည်၊ CLR သည် GC ကို ဖော်ထုတ်ပြီး ဖရီးဇ်များ စတင်သည်။ သိသိသာသာနှေးနေသင့်တယ် ယုံပါ ။ ခေတ်မီထုတ်လုပ်ရေးဆာဗာများ သို့မဟုတ် cloud စက်များတွင် ကြီးမားသော memory ပမာဏသည် မြင့်မားသောလုပ်ဆောင်မှုနှောင့်နှေးမှုကို မတားဆီးနိုင်ပါ။ တကယ်တော့၊ memory များလေ၊ GC အလုပ်လုပ်ပုံကို သတိပြုမိဖို့ အလားအလာ ပိုများလေပါပဲ။ Reflection သည် သီအိုရီအရ သူ့အတွက် အပိုအနီရောင်အ၀တ်အစားတစ်ခုဖြစ်သည်။

သို့သော်လည်း၊ ကျွန်ုပ်တို့အားလုံးသည် IoC ကွန်တိန်နာများနှင့် ရက်စွဲမြေပုံပရိုဂရမ်များကို ရောင်ပြန်ဟပ်မှုအပေါ်အခြေခံသည့် လည်ပတ်မှုနိယာမကို အသုံးပြုကြသည်၊ သို့သော် များသောအားဖြင့် ၎င်းတို့၏စွမ်းဆောင်ရည်နှင့်ပတ်သက်ပြီး မေးခွန်းထုတ်စရာမရှိပါ။ မဟုတ်ပါ၊ ပြင်ပအကန့်အသတ်ရှိသော ဆက်စပ်ပုံစံများမှ မှီခိုမှုနှင့် abstraction များကို နိဒါန်းပျိုးခြင်းသည် မည်သည့်ကိစ္စတွင်မဆို ကျွန်ုပ်တို့၏စွမ်းဆောင်ရည်ကို စတေးရရန် အလွန်လိုအပ်သောကြောင့် မဟုတ်ပါ။ အရာအားလုံးက ပိုရိုးရှင်းပါတယ် - စွမ်းဆောင်ရည်ကို သိပ်ပြီးတော့ မထိခိုက်စေပါဘူး။

အမှန်မှာ ရောင်ပြန်ဟပ်မှုနည်းပညာကိုအခြေခံသည့် အသုံးအများဆုံးဘောင်များသည် ၎င်းနှင့်ပို၍အကောင်းဆုံးလုပ်ဆောင်ရန် လှည့်ကွက်မျိုးစုံကိုအသုံးပြုပါသည်။ များသောအားဖြင့် ၎င်းသည် ကက်ရှ်တစ်ခုဖြစ်သည်။ ပုံမှန်အားဖြင့် ၎င်းတို့သည် စကားရပ်သစ်ပင်မှ စုစည်းထားသော စကားရပ်များနှင့် ကိုယ်စားလှယ်များဖြစ်သည်။ တူညီသော automapper သည် ရောင်ပြန်ဟပ်မှုကို မခေါ်ဆိုဘဲ တစ်ခုမှ တစ်ခုသို့ ပြောင်းလဲနိုင်သည့် လုပ်ဆောင်ချက်အမျိုးအစားများနှင့် ကိုက်ညီသည့် ပြိုင်ဆိုင်မှုရှိသော အဘိဓာန်ကို ထိန်းသိမ်းထားသည်။

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

ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ သင်သည် JIT စုစည်းမှုကိုလည်း အသုံးပြုနိုင်ပြီး ၎င်းမှ AOT မိတ်ဖက်များကဲ့သို့ တူညီသောစွမ်းဆောင်ရည်ဖြင့် စုစည်းထားသောအပြုအမူကို အသုံးပြုနိုင်သည်။ ဤကိစ္စတွင် ထုတ်ဖော်ပြောဆိုမှုများသည် ကျွန်ုပ်တို့ထံသို့ ရောက်ရှိလာမည်ဖြစ်သည်။

မေးခွန်းအတွက် နိယာမကို အောက်ပါအတိုင်း အတိုချုံး ရေးဆွဲနိုင်ပါသည်။
စုစည်းထားသောလုပ်ဆောင်ချက်ပါရှိသော ကိုယ်စားလှယ်တစ်ဦးအနေဖြင့် ရောင်ပြန်ဟပ်မှု၏နောက်ဆုံးရလဒ်ကို သိမ်းဆည်းထားသင့်သည်။ အရာဝတ္တုအပြင်ဘက်တွင် သိမ်းဆည်းထားသည့် သင့်အမျိုးအစား၊ အလုပ်သမား၊ နယ်ပယ်များတွင် လိုအပ်သော အရာဝတ္ထုအားလုံးကို အမျိုးအစားအချက်အလက်ဖြင့် ကက်ရှ်လုပ်ခြင်းသည်လည်း အဓိပ္ပာယ်ရှိစေသည်။

ဒီထဲမှာ ယုတ္တိရှိတယ်။ တစ်ခုခုကို စုစည်းပြီး ကက်ရှ်လုပ်နိုင်ရင် လုပ်သင့်တယ်လို့ သာမာန်အသိက ပြောထားတယ်။

ရှေ့ကိုကြည့်ခြင်းအားဖြင့်၊ ရောင်ပြန်ဟပ်မှုနှင့်အတူအလုပ်လုပ်သည့် cache သည် အဆိုပြုထားသောအသုံးအနှုန်းများကိုစုစည်းသည့်နည်းလမ်းကိုအသုံးမပြုလျှင်တောင်မှ၎င်း၏အားသာချက်များရှိသည်ဟုဆိုရပါမည်။ တကယ်တော့ ဒီနေရာမှာ ကျွန်တော် အထက်ဖော်ပြပါ ဆောင်းပါးရေးသူရဲ့ ဒီအချက်တွေကို ထပ်ခါတလဲလဲ ပြောတာပါ။

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

အနှစ်သာရရှိတယ်။ ဆက်သွယ်မှုရှိပါစေ။ parser နှင့် hydrator တို့မှ ဤတူညီသောအဆက်အသွယ်များကို ဖန်တီးပေးသော စံသတ်မှတ်ထားသော ကိုယ်ထည်ပါသော စာလုံးများရှိပါသည်။ စာတစ်စောင်ရောက်လာသည်၊ ကျွန်ုပ်တို့သည် ၎င်းကိုဖတ်ပြီး၊ ၎င်းကို သော့တန်ဖိုးအတွဲများအဖြစ် ခွဲခြမ်းစိပ်ဖြာကာ အဆက်အသွယ်တစ်ခုကို ဖန်တီးကာ ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသည်။

မူလတန်း။ အဆက်အသွယ်တစ်ခုတွင် အမည်အပြည့်အစုံ၊ အသက်နှင့် ဆက်သွယ်ရန်ဖုန်း၏ ဂုဏ်သတ္တိများရှိသည်ဆိုကြပါစို့။ ဤအချက်အလက်ကို စာထဲတွင် ပေးပို့ပါသည်။ လုပ်ငန်းသည် အက္ခရာ၏ကိုယ်ထည်ရှိ အရာဝတ္ထုများကို အတွဲများအဖြစ် မြေပုံဆွဲခြင်းအတွက် သော့အသစ်များကို အမြန်ထည့်နိုင်စေရန် ပံ့ပိုးကူညီလိုပါသည်။ တစ်စုံတစ်ဦးသည် နမူနာပုံစံတွင် အမှားလုပ်မိပါက သို့မဟုတ် မထုတ်ဝေမီတွင် ဖော်မတ်အသစ်နှင့် လိုက်လျောညီထွေဖြစ်အောင် ဖော်မတ်အသစ်မှ မြေပုံဆွဲခြင်းကို အမြန်စတင်ရန် လိုအပ်ပါသည်။ ထို့နောက် ကျွန်ုပ်တို့သည် စျေးသက်သာသော datafix တစ်ခုအဖြစ် မြေပုံညွှန်းဆက်စပ်မှုအသစ်တစ်ခုကို ထည့်နိုင်သည်။ ဆိုလိုသည်မှာ ဘဝဥပမာတစ်ခုဖြစ်သည်။

ကျွန်ုပ်တို့သည် စမ်းသပ်မှုများကို ဖန်တီး၍ အကောင်အထည်ဖော်သည်။ အလုပ်များ။

ကုဒ်ကို ကျွန်ုပ်ပေးမည်မဟုတ်ပါ- ရင်းမြစ်များစွာရှိပြီး ၎င်းတို့ကို ဆောင်းပါး၏အဆုံးတွင် လင့်ခ်မှတစ်ဆင့် GitHub တွင် ရနိုင်ပါသည်။ သင့်ကိစ္စတွင် သက်ရောက်မှုရှိနိုင်သောကြောင့် ၎င်းတို့ကို တင်ဆောင်နိုင်သည်၊ ၎င်းတို့ကို အသိအမှတ်မပြုဘဲ နှိပ်စက်ညှဉ်းပန်းကာ တိုင်းတာနိုင်ပါသည်။ နှေးသည်ဟုယူဆရသည့် hydrator နှင့် အမြန်ဟုယူဆရသည့် hydrator ကိုခွဲခြားသည့် template method နှစ်ခု၏ကုဒ်ကို ကျွန်တော်ပေးပါမည်။

ယုတ္တိဗေဒမှာ အောက်ပါအတိုင်းဖြစ်သည်- နမူနာပုံစံနည်းလမ်းသည် အခြေခံ parser logic မှထုတ်ပေးသောအတွဲများကို လက်ခံရရှိသည် ။ LINQ အလွှာသည် ဒေတာဘေ့စ်အကြောင်းအရာသို့ တောင်းဆိုချက်တစ်ခုပြုလုပ်ကာ parser မှအတွဲများနှင့် နှိုင်းယှဉ်ပေးသည့် parser နှင့် hydrator ၏ အခြေခံယုတ္တိယုတ္တိဖြစ်ပြီး၊ parser မှအတွဲများနှင့် နှိုင်းယှဉ်သည် (ဤလုပ်ဆောင်ချက်များအတွက် နှိုင်းယှဉ်ရန်အတွက် LINQ မပါသောကုဒ်များရှိသည်)။ ထို့နောက် အတွဲများကို main hydration method သို့ ပေးပို့ပြီး အတွဲများ၏ တန်ဖိုးများကို entity ၏ သက်ဆိုင်ရာ ဂုဏ်သတ္တိများအဖြစ် သတ်မှတ်ထားသည်။

“Fast” (စံနှုန်းများတွင် ရှေ့ထွက်အမြန်)

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

ကျွန်ုပ်တို့မြင်နိုင်သည်အတိုင်း၊ setter properties ပါရှိသော static collection ကို setter entity ဟုခေါ်သော compiled lambdas ကိုအသုံးပြုသည်။ အောက်ပါကုဒ်ဖြင့် ဖန်တီးထားသည်-

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

ယေဘုယျအားဖြင့် ရှင်းပါသည်။ ကျွန်ုပ်တို့သည် ပိုင်ဆိုင်မှုများကို ဖြတ်ကျော်ကာ၊ setters ဟုခေါ်သော သူတို့အတွက် ကိုယ်စားလှယ်များကို ဖန်တီးကာ ၎င်းတို့ကို သိမ်းဆည်းပါသည်။ ပြီးရင် လိုအပ်ရင် ဖုန်းဆက်ပါ။

“နှေးကွေးခြင်း” (စံသတ်မှတ်ချက်များတွင် ရှေ့နောက် နှေးသည်)

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

ဤနေရာတွင် ကျွန်ုပ်တို့သည် ဂုဏ်သတ္တိများကို ချက်ချင်းကျော်ဖြတ်ပြီး SetValue ကို တိုက်ရိုက်ခေါ်ဆိုပါ။

ရှင်းလင်းပြတ်သားပြီး အကိုးအကားအတွက်၊ ၎င်းတို့၏ ဆက်စပ်အတွဲများ၏ တန်ဖိုးများကို entity အကွက်များသို့ တိုက်ရိုက်ရေးသားသည့် နုံအသောနည်းလမ်းကို အကောင်အထည်ဖော်ခဲ့သည်။ ရှေ့ဆက် - လက်စွဲစာအုပ်။

အခု BenchmarkDotNet ကိုယူပြီး စွမ်းဆောင်ရည်ကို စစ်ဆေးကြည့်ရအောင်။ ရုတ်တရက်... (spoiler - ဒါက မှန်ကန်တဲ့ရလဒ်မဟုတ်ပါဘူး၊ အသေးစိတ်ကို အောက်မှာဖော်ပြထားပါတယ်)

ငါတို့ ဒီမှာ ဘာမြင်လဲ။ Fast prefix ကို အောင်ပွဲခံနိုင်သော နည်းလမ်းများသည် Slow prefix ရှိသည့် နည်းလမ်းများထက် ဖြတ်သန်းမှုအားလုံးနီးပါးတွင် နှေးကွေးသွားပါသည်။ ဤသည်မှာ ခွဲဝေမှုနှင့် အလုပ်၏အရှိန်နှစ်ခုလုံးအတွက် မှန်ပါသည်။ အခြားတစ်ဖက်တွင်၊ ၎င်းအတွက် ရည်ရွယ်သည့် LINQ နည်းလမ်းများကို အသုံးပြု၍ လှပပြေပြစ်သော မြေပုံဆွဲခြင်း အကောင်အထည်ဖော်ခြင်းသည် ဆန့်ကျင်ဘက်အနေဖြင့် ဖြစ်နိုင်သမျှနေရာတိုင်းတွင် ကုန်ထုတ်စွမ်းအားကို များစွာလျှော့ချပေးပါသည်။ ကွာခြားချက်မှာ အမိန့်ဖြစ်သည်။ ဖြတ်သန်းခွင့် အရေအတွက် အမျိုးမျိုးဖြင့် ပြောင်းလဲခြင်း မရှိပါ။ တစ်ခုတည်းသော ခြားနားချက်မှာ အတိုင်းအတာဖြစ်သည်။ LINQ ဖြင့်၎င်းသည် 4-200 ဆနှေးသည်၊ ခန့်မှန်းခြေအားဖြင့်တူညီသောအတိုင်းအတာတွင်အမှိုက်ပိုများသည်။

ပြုပြင်မွမ်းမံ

ငါ့မျက်လုံးတွေကို ငါမယုံဘူး၊ ဒါပေမယ့် ပိုအရေးကြီးတာက ငါတို့လုပ်ဖော်ကိုင်ဖက်က ငါ့မျက်လုံး ဒါမှမဟုတ် ငါ့ကုဒ်ကို မယုံခဲ့ဘူး၊ Dmitry Tikhonov 0x1000000. ကျွန်ုပ်၏ဖြေရှင်းချက်ကို နှစ်ခါစစ်ဆေးပြီးနောက်၊ အကောင်အထည်ဖော်မှုတွင် အပြောင်းအလဲများစွာကြောင့် လွဲချော်ခဲ့သော အမှားတစ်ခုကို ထက်မြက်စွာ ရှာဖွေတွေ့ရှိခဲ့ပြီး ကနဦးမှ အပြီးသတ်ခဲ့သည်။ Moq စနစ်ထည့်သွင်းမှုတွင် တွေ့ရှိသော ချို့ယွင်းချက်အား ပြုပြင်ပြီးနောက် ရလဒ်များအားလုံးသည် နေရာသို့ ကျသွားသည်။ ပြန်လည်စစ်ဆေးမှုရလဒ်များအရ၊ အဓိကလမ်းကြောင်းသည် ပြောင်းလဲခြင်းမရှိပါ - LINQ သည် ရောင်ပြန်ဟပ်မှုထက် စွမ်းဆောင်ရည်ကို ပိုမိုသက်ရောက်မှုရှိနေဆဲဖြစ်သည်။ သို့ရာတွင်၊ Expression compilation ဖြင့် လုပ်ဆောင်ခြင်းသည် အချည်းနှီးမဖြစ်ဘဲ၊ ခွဲဝေမှုနှင့် အကောင်အထည်ဖော်ချိန်တို့တွင် ရလဒ်ကို မြင်နိုင်သည်မှာ ကောင်းပါတယ်။ အငြိမ်အကွက်များကို အစပြုသောအခါ ပထမလွှတ်တင်မှုသည် "မြန်" နည်းလမ်းအတွက် သဘာဝအတိုင်း နှေးကွေးသော်လည်း နောက်ပိုင်းတွင် အခြေအနေ ပြောင်းလဲသွားသည်။

ဤသည်မှာ ပြန်လည်စစ်ဆေးမှု၏ ရလဒ်ဖြစ်သည်။

နိဂုံး- လုပ်ငန်းတစ်ခုတွင် ရောင်ပြန်ဟပ်မှုကို အသုံးပြုသည့်အခါ၊ လှည့်ကွက်များကို ကိုးကားရန် သီးသန့်မလိုအပ်ပါ - LINQ သည် ကုန်ထုတ်စွမ်းအားကို ပိုစားစေသည်။ သို့ရာတွင်၊ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ရန် လိုအပ်သည့် ဝန်ထုပ်ဝန်ပိုးမြင့်မားသောနည်းလမ်းများတွင်၊ ထို့နောက် "မြန်ဆန်" ယုတ္တိကိုပေးစွမ်းမည့် ကနဦးအစပြုသူများနှင့် ကိုယ်စားလှယ်စာဖွဲ့မှုပုံစံဖြင့် ရောင်ပြန်ဟပ်မှုကို သိမ်းဆည်းနိုင်သည်။ ဤနည်းဖြင့် သင်သည် ရောင်ပြန်ဟပ်မှု၏ ပြောင်းလွယ်ပြင်လွယ်နှင့် အပလီကေးရှင်း၏ အမြန်နှုန်းကို ထိန်းသိမ်းနိုင်သည်။

စံကုဒ်ကို ဤနေရာတွင် ရနိုင်ပါသည်။ မည်သူမဆို ကျွန်ုပ်၏စကားကို နှစ်ဆစစ်ဆေးနိုင်သည်-
Habra Reflection Tests

PS- စမ်းသပ်မှုများရှိကုဒ်သည် IoC ကိုအသုံးပြုပြီး စံသတ်မှတ်ချက်များတွင် ၎င်းသည် ရှင်းလင်းပြတ်သားသောတည်ဆောက်မှုကို အသုံးပြုသည်။ အမှန်မှာ နောက်ဆုံး အကောင်အထည်ဖော်မှုတွင် စွမ်းဆောင်ရည်ကို ထိခိုက်စေနိုင်ပြီး ရလဒ်ကို ဆူညံစေမည့် အချက်အားလုံးကို ဖြတ်တောက်လိုက်ခြင်းဖြစ်သည်။

PPS- အသုံးပြုသူကို ကျေးဇူးတင်ပါသည်။ Dmitry Tikhonov @0x1000000 Moq ကို စတင်သတ်မှတ်ရာတွင် ကျွန်ုပ်၏အမှားကို ရှာဖွေတွေ့ရှိသည့်အတွက်၊ ပထမတိုင်းတာမှုများကို ထိခိုက်စေပါသည်။ စာဖတ်သူ တစ်စုံတစ်ယောက်အတွက် လုံလောက်သော ကုသိုလ်ကံ ရှိပါက ကျေးဇူးပြု၍ ကျေးဇူးပြု၍ လူက ရပ်လိုက်၊ ဖတ်လိုက်၊ အဲဒီလူက အမှားကို နှစ်ခါပြန်စစ်ပြီး အမှားကို ထောက်ပြတယ်။ ဒါဟာ လေးစားမှုနဲ့ ကိုယ်ချင်းစာသင့်တယ်လို့ ထင်ပါတယ်။

PPPS - စတိုင်လ်နှင့် ဒီဇိုင်း၏ အောက်ခြေသို့ ရောက်အောင် စေ့စေ့စပ်စပ်ဖတ်သူအား ကျေးဇူးတင်ပါသည်။ ငါသည် တူညီမှုနှင့် အဆင်ပြေမှု အတွက်ဖြစ်သည်။ တင်ပြချက်၏ သံခင်းတမန်ခင်းသည် များစွာလိုလားတောင့်တနေသော်လည်း ဝေဖန်မှုကို ထည့်သွင်းစဉ်းစားမိပါသည်။ ကျည်ဆန်တွေတောင်းတယ်။

source: www.habr.com