អត្ថបទមិនជោគជ័យអំពីការពន្លឿនការឆ្លុះបញ្ចាំង

ខ្ញុំនឹងពន្យល់ពីចំណងជើងអត្ថបទភ្លាមៗ។ ផែនការដើមគឺផ្តល់ដំបូន្មានល្អ និងអាចទុកចិត្តបានអំពីរបៀបបង្កើនល្បឿននៃការប្រើប្រាស់ការឆ្លុះបញ្ចាំងដោយប្រើឧទាហរណ៍សាមញ្ញ ប៉ុន្តែជាក់ស្តែង ប៉ុន្តែក្នុងអំឡុងពេលធ្វើការវាស់វែង វាបានបង្ហាញថាការឆ្លុះបញ្ចាំងមិនយឺតដូចខ្ញុំបានគិតទេ LINQ គឺយឺតជាងសុបិន្តអាក្រក់របស់ខ្ញុំ។ ប៉ុន្តែនៅទីបញ្ចប់ វាបានប្រែក្លាយថាខ្ញុំក៏មានកំហុសក្នុងការវាស់វែង... ព័ត៌មានលម្អិតនៃរឿងរ៉ាវជីវិតនេះគឺស្ថិតនៅក្រោមការកាត់ត និងនៅក្នុងមតិយោបល់។ ចាប់តាំងពីឧទាហរណ៍នេះគឺជារឿងធម្មតាហើយត្រូវបានអនុវត្តជាគោលការណ៍ដូចដែលត្រូវបានធ្វើឡើងជាធម្មតានៅក្នុងសហគ្រាសមួយវាបានប្រែទៅជាគួរឱ្យចាប់អារម្មណ៍ណាស់ដូចដែលវាហាក់ដូចជាខ្ញុំ ការបង្ហាញជីវិត: ផលប៉ះពាល់លើល្បឿននៃប្រធានបទសំខាន់នៃអត្ថបទគឺ មិនអាចកត់សម្គាល់បានទេដោយសារតែតក្កវិជ្ជាខាងក្រៅ: Moq, Autofac, EF Core និង "ក្រុមតន្រ្តី" ផ្សេងទៀត។

ខ្ញុំចាប់ផ្តើមធ្វើការក្រោមចំណាប់អារម្មណ៍នៃអត្ថបទនេះ៖ ហេតុអ្វីបានជាការឆ្លុះបញ្ចាំងយឺត

ដូចដែលអ្នកអាចឃើញ អ្នកនិពន្ធស្នើឱ្យប្រើប្រតិភូដែលបានចងក្រងជាជាងការហៅដោយផ្ទាល់នូវវិធីសាស្ត្រប្រភេទឆ្លុះបញ្ចាំងជាមធ្យោបាយដ៏ល្អក្នុងការបង្កើនល្បឿនកម្មវិធីយ៉ាងខ្លាំង។ ជាការពិតណាស់មានការបំភាយ IL ប៉ុន្តែខ្ញុំចង់ជៀសវាងវា ព្រោះនេះជាវិធីដែលពឹងផ្អែកលើកម្លាំងពលកម្មបំផុតក្នុងការអនុវត្តការងារ ដែលវាពោរពេញដោយកំហុស។

ដោយពិចារណាថាខ្ញុំតែងតែមានគំនិតស្រដៀងគ្នាអំពីល្បឿននៃការឆ្លុះបញ្ចាំង ខ្ញុំមិនមានបំណងពិសេសដើម្បីសួរការសន្និដ្ឋានរបស់អ្នកនិពន្ធនោះទេ។

ជារឿយៗខ្ញុំជួបប្រទះការប្រើការឆ្លុះបញ្ចាំងដោយឆោតល្ងង់នៅក្នុងសហគ្រាស។ ប្រភេទត្រូវបានយក។ ព័ត៌មានអំពីទ្រព្យសម្បត្តិត្រូវបានយក។ វិធីសាស្ត្រ SetValue ត្រូវបានគេហៅថា ហើយគ្រប់គ្នារីករាយ។ តម្លៃបានមកដល់វាលគោលដៅ អ្នកទាំងអស់គ្នាសប្បាយចិត្ត។ មនុស្សឆ្លាតណាស់ - មនុស្សចាស់ និងអ្នកដឹកនាំក្រុម - សរសេរផ្នែកបន្ថែមរបស់ពួកគេដើម្បីជំទាស់ ដោយផ្អែកលើការអនុវត្តបែបឆោតល្ងង់ "ជាសកល" អ្នកធ្វើផែនទីពីប្រភេទមួយទៅប្រភេទមួយទៀត។ ខ្លឹមសារជាធម្មតាគឺ៖ យើងយកវាលទាំងអស់ យកលក្ខណៈសម្បត្តិទាំងអស់ ធ្វើម្តងទៀតលើពួកវា៖ ប្រសិនបើឈ្មោះនៃប្រភេទសមាជិកត្រូវគ្នា យើងប្រតិបត្តិ SetValue ។ ពីពេលមួយទៅពេលមួយ យើងចាប់បានករណីលើកលែងដោយសារតែកំហុសដែលយើងមិនបានរកឃើញទ្រព្យសម្បត្តិមួយចំនួននៅក្នុងប្រភេទណាមួយ ប៉ុន្តែសូម្បីតែនៅទីនេះក៏មានវិធីដែលធ្វើអោយប្រសើរឡើងនូវការអនុវត្ត។ សាកល្បង/ចាប់។

ខ្ញុំបានឃើញមនុស្សបង្កើតឧបករណ៍ញែក និងអ្នកបង្កើតផែនទីឡើងវិញដោយមិនមានអាវុធពេញលេញជាមួយនឹងព័ត៌មានអំពីរបៀបដែលម៉ាស៊ីនដែលមកមុនពួកគេដំណើរការ។ ខ្ញុំបានឃើញមនុស្សលាក់ការអនុវត្តដ៏ឆោតល្ងង់របស់ពួកគេនៅពីក្រោយយុទ្ធសាស្រ្ត នៅពីក្រោយចំណុចប្រទាក់ នៅពីក្រោយការចាក់ ដូចជាប្រសិនបើការនេះនឹងដោះសារចំពោះ bacchanalia ជាបន្តបន្ទាប់។ ខ្ញុំបានបើកច្រមុះរបស់ខ្ញុំនៅពេលដឹងការពិតបែបនេះ។ តាមពិតទៅ ខ្ញុំមិនបានវាស់ស្ទង់ការលេចធ្លាយនៃការអនុវត្តជាក់ស្តែងទេ ហើយប្រសិនបើអាចធ្វើទៅបាន ខ្ញុំគ្រាន់តែផ្លាស់ប្តូរការអនុវត្តទៅជា "ល្អបំផុត" បន្ថែមទៀត ប្រសិនបើខ្ញុំអាចចាប់ដៃខ្ញុំបាន។ ដូច្នេះ ការវាស់វែងដំបូងដែលបានពិភាក្សាខាងក្រោមធ្វើឱ្យខ្ញុំយល់ច្រឡំយ៉ាងធ្ងន់ធ្ងរ។

ខ្ញុំគិតថាអ្នកជាច្រើនដែលអាន Richter ឬអ្នកមនោគមវិជ្ជាផ្សេងទៀតបានឆ្លងកាត់សេចក្តីថ្លែងការណ៍ត្រឹមត្រូវទាំងស្រុងដែលការឆ្លុះបញ្ចាំងនៅក្នុងកូដគឺជាបាតុភូតដែលមានផលប៉ះពាល់អវិជ្ជមានយ៉ាងខ្លាំងលើការអនុវត្តកម្មវិធី។

ការហៅការឆ្លុះបញ្ចាំងបង្ខំឱ្យ CLR ឆ្លងកាត់ការជួបប្រជុំគ្នា ដើម្បីស្វែងរកអ្វីដែលពួកគេត្រូវការ ទាញយកទិន្នន័យមេតារបស់ពួកគេ ញែកពួកវា។ល។ លើសពីនេះ ការឆ្លុះបញ្ជាំងខណៈពេលដែលឆ្លងកាត់តាមលំដាប់លំដោយនាំទៅដល់ការបែងចែកនៃការចងចាំយ៉ាងច្រើន។ យើងកំពុងប្រើប្រាស់អង្គចងចាំ ហើយ CLR បើក GC ហើយការបង្កកចាប់ផ្តើម។ វាគួរតែយឺតគួរឱ្យកត់សម្គាល់ ជឿខ្ញុំ។ បរិមាណអង្គចងចាំដ៏ច្រើននៅលើម៉ាស៊ីនមេផលិតកម្មទំនើប ឬម៉ាស៊ីនពពកមិនការពារការពន្យារពេលដំណើរការខ្ពស់នោះទេ។ ជាការពិត ការចងចាំកាន់តែច្រើន អ្នកទំនងជានឹងកត់សម្គាល់ពីរបៀបដែល GC ដំណើរការ។ តាមទ្រឹស្ដី ការឆ្លុះបញ្ចាំងគឺជាក្រណាត់ក្រហមបន្ថែមសម្រាប់គាត់។

ទោះជាយ៉ាងណាក៏ដោយ យើងទាំងអស់គ្នាប្រើ IoC containers និង date mappers ដែលជាគោលការណ៍ប្រតិបត្តិការដែលផ្អែកលើការឆ្លុះបញ្ចាំងផងដែរ ប៉ុន្តែជាធម្មតាមិនមានសំណួរអំពីដំណើរការរបស់វាទេ។ ទេ មិនមែនដោយសារតែការណែនាំនៃភាពអាស្រ័យ និងការអរូបីពីគំរូបរិបទដែលមានកម្រិតខាងក្រៅគឺចាំបាច់ណាស់ដែលយើងត្រូវលះបង់ការអនុវត្តក្នុងករណីណាក៏ដោយ។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញជាង - វាពិតជាមិនប៉ះពាល់ដល់ការអនុវត្តច្រើនទេ។

ការពិតគឺថាក្របខ័ណ្ឌទូទៅបំផុតដែលផ្អែកលើបច្ចេកវិទ្យាឆ្លុះបញ្ចាំងប្រើល្បិចគ្រប់ប្រភេទដើម្បីធ្វើការជាមួយវាកាន់តែល្អប្រសើរ។ ជាធម្មតានេះគឺជាឃ្លាំងសម្ងាត់។ ជាធម្មតាទាំងនេះគឺជាកន្សោម និងប្រតិភូដែលបានចងក្រងពីមែកធាងកន្សោម។ automapper ដូចគ្នារក្សាវចនានុក្រមប្រកួតប្រជែងដែលផ្គូផ្គងប្រភេទជាមួយនឹងមុខងារដែលអាចបំប្លែងមួយទៅជាមួយផ្សេងទៀតដោយមិនហៅការឆ្លុះបញ្ចាំង។

តើនេះសម្រេចបានដោយរបៀបណា? សំខាន់ វាមិនខុសពីតក្កវិជ្ជាដែលវេទិកាខ្លួនឯងប្រើដើម្បីបង្កើតកូដ JIT នោះទេ។ នៅពេលដែលវិធីសាស្រ្តមួយត្រូវបានហៅជាលើកដំបូង វាត្រូវបានចងក្រង (ហើយបាទ ដំណើរការនេះមិនលឿនទេ) នៅលើការហៅជាបន្តបន្ទាប់ ការគ្រប់គ្រងត្រូវបានផ្ទេរទៅវិធីសាស្ត្រដែលបានចងក្រងរួចហើយ ហើយវានឹងមិនមានការអូសទាញដំណើរការសំខាន់ៗទេ។

ក្នុងករណីរបស់យើង អ្នកក៏អាចប្រើការចងក្រង JIT ហើយបន្ទាប់មកប្រើឥរិយាបថចងក្រងជាមួយនឹងការអនុវត្តដូចគ្នានឹងសមភាគី AOT របស់វា។ ការបញ្ចេញមតិនឹងមករកជំនួយរបស់យើងក្នុងករណីនេះ។

គោលការណ៍នៅក្នុងសំណួរអាចត្រូវបានបង្កើតដោយសង្ខេបដូចខាងក្រោម:
អ្នកគួរតែរក្សាទុកលទ្ធផលចុងក្រោយនៃការឆ្លុះបញ្ចាំងជាប្រតិភូដែលមានមុខងារចងក្រង។ វាក៏សមហេតុផលផងដែរក្នុងការរក្សាទុកវត្ថុចាំបាច់ទាំងអស់ជាមួយនឹងព័ត៌មានប្រភេទនៅក្នុងវាលនៃប្រភេទរបស់អ្នក កម្មករ ដែលត្រូវបានរក្សាទុកនៅខាងក្រៅវត្ថុ។

មានតក្កវិជ្ជានៅក្នុងរឿងនេះ។ សតិអារម្មណ៍ប្រាប់យើងថា ប្រសិនបើមានអ្វីមួយអាចចងក្រង និងទុកក្នុងឃ្លាំងសម្ងាត់បាន នោះវាគួរតែត្រូវបានធ្វើ។

សម្លឹងទៅមុខ វាគួរតែត្រូវបាននិយាយថាឃ្លាំងសម្ងាត់ក្នុងការធ្វើការជាមួយការឆ្លុះបញ្ចាំងមានគុណសម្បត្តិរបស់វា ទោះបីជាអ្នកមិនប្រើវិធីសាស្ត្រដែលបានស្នើឡើងក្នុងការចងក្រងកន្សោមក៏ដោយ។ តាមពិតទៅ នៅទីនេះខ្ញុំគ្រាន់តែនិយាយឡើងវិញនូវអត្ថបទរបស់អ្នកនិពន្ធអត្ថបទដែលខ្ញុំយោងខាងលើ។

ឥឡូវនេះអំពីលេខកូដ។ សូមក្រឡេកមើលឧទាហរណ៍មួយដែលផ្អែកលើការឈឺចាប់នាពេលថ្មីៗនេះរបស់ខ្ញុំដែលខ្ញុំត្រូវប្រឈមមុខនៅក្នុងការផលិតដ៏ធ្ងន់ធ្ងរនៃស្ថាប័នឥណទានដ៏ធ្ងន់ធ្ងរមួយ។ អង្គភាពទាំងអស់សុទ្ធតែប្រឌិត ដូច្នេះគ្មាននរណាម្នាក់ស្មាន

មានខ្លឹមសារខ្លះ។ អនុញ្ញាតឱ្យមានទំនាក់ទំនង។ មានអក្សរដែលមានតួអត្ថបទស្តង់ដារ ដែលឧបករណ៍ញែក និង hydrator បង្កើតទំនាក់ទំនងដូចគ្នាទាំងនេះ។ សំបុត្រមួយបានមកដល់ យើងអានវា ញែកវាទៅជាគូតម្លៃគន្លឹះ បង្កើតទំនាក់ទំនង និងរក្សាទុកវាក្នុងមូលដ្ឋានទិន្នន័យ។

វាជាបឋម។ ឧបមាថាទំនាក់ទំនងមានលក្ខណសម្បត្តិ ឈ្មោះពេញ អាយុ និងទូរសព្ទទំនាក់ទំនង។ ទិន្នន័យនេះត្រូវបានបញ្ជូនតាមសំបុត្រ។ អាជីវកម្មក៏ចង់បានការគាំទ្រផងដែរ ដើម្បីអាចបន្ថែមសោថ្មីយ៉ាងឆាប់រហ័សសម្រាប់ការគូសផែនទីវត្ថុធាតុទៅជាគូនៅក្នុងតួអក្សរ។ ក្នុងករណីដែលនរណាម្នាក់ធ្វើខុសនៅក្នុងគំរូ ឬប្រសិនបើមុនពេលចេញផ្សាយ ចាំបាច់ត្រូវចាប់ផ្តើមការគូសផែនទីជាបន្ទាន់ពីដៃគូថ្មី ដោយសម្របខ្លួនទៅនឹងទម្រង់ថ្មី។ បន្ទាប់មកយើងអាចបន្ថែមការជាប់ទាក់ទងគ្នានៃផែនទីថ្មីមួយជា datafix ថោក។ នោះ​គឺ​ជា​ឧទាហរណ៍​ជីវិត។

យើងអនុវត្ត, បង្កើតការធ្វើតេស្ត។ ការងារ។

ខ្ញុំនឹងមិនផ្តល់លេខកូដទេ៖ មានប្រភពជាច្រើន ហើយពួកវាមាននៅលើ GitHub តាមរយៈតំណភ្ជាប់នៅចុងបញ្ចប់នៃអត្ថបទ។ អ្នកអាចផ្ទុកពួកវា ធ្វើទារុណកម្មពួកគេលើសពីការទទួលស្គាល់ និងវាស់ស្ទង់ពួកវា ដូចដែលវានឹងប៉ះពាល់ដល់ករណីរបស់អ្នក។ ខ្ញុំនឹងផ្តល់លេខកូដនៃវិធីសាស្ត្រគំរូពីរប៉ុណ្ណោះដែលបែងចែក hydrator ដែលសន្មត់ថាលឿន ពី hydrator ដែលសន្មត់ថាយឺត។

តក្កវិជ្ជាមានដូចខាងក្រោម៖ វិធីសាស្ត្រគំរូទទួលបានគូដែលបង្កើតដោយតក្កវិជ្ជាញែកមូលដ្ឋាន។ ស្រទាប់ LINQ គឺជាអ្នកញែក និងតក្កវិជ្ជាមូលដ្ឋានរបស់ hydrator ដែលធ្វើការស្នើសុំទៅកាន់បរិបទមូលដ្ឋានទិន្នន័យ ហើយប្រៀបធៀបសោជាមួយគូពីឧបករណ៍ញែក (សម្រាប់មុខងារទាំងនេះមានកូដដោយគ្មាន LINQ សម្រាប់ប្រៀបធៀប)។ បន្ទាប់មក គូត្រូវបានបញ្ជូនទៅវិធីសាស្ត្រ hydration ចម្បង ហើយតម្លៃនៃគូត្រូវបានកំណត់ទៅលក្ខណៈសម្បត្តិដែលត្រូវគ្នានៃអង្គភាព។

"លឿន" (បុព្វបទលឿនក្នុងតារាងពិន្ទុ)៖

 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 ត្រូវបានប្រើ - lambdas ចងក្រងដែលហៅថា setter entity ។ បង្កើតដោយកូដខាងក្រោម៖

        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();
        }

ជាទូទៅវាច្បាស់ណាស់។ យើងឆ្លងកាត់លក្ខណៈសម្បត្តិ បង្កើតប្រតិភូសម្រាប់ពួកគេ ដែលហៅអ្នកកំណត់ និងរក្សាទុកពួកវា។ បន្ទាប់មកយើងហៅនៅពេលចាំបាច់។

"យឺត" (បុព្វបទ យឺតក្នុងតារាងពិន្ទុ)៖

        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 ដោយផ្ទាល់។

សម្រាប់ភាពច្បាស់លាស់ និងជាឯកសារយោង ខ្ញុំបានអនុវត្តវិធីសាស្ត្រឆោតល្ងង់ ដែលសរសេរតម្លៃនៃគូទំនាក់ទំនងរបស់ពួកគេដោយផ្ទាល់ទៅក្នុងវាលអង្គភាព។ បុព្វបទ - សៀវភៅដៃ។

ឥឡូវនេះសូមយក BenchmarkDotNet ហើយពិនិត្យមើលការអនុវត្ត។ ហើយភ្លាមៗ ... (spoiler - នេះមិនមែនជាលទ្ធផលត្រឹមត្រូវទេ ព័ត៌មានលម្អិតមាននៅខាងក្រោម)

តើយើងឃើញអ្វីនៅទីនេះ? វិធីសាស្រ្តដែលទទួលជ័យជំនះលើបុព្វបទ Fast ប្រែទៅជាយឺតជាងក្នុងការឆ្លងកាត់ស្ទើរតែទាំងអស់ជាងវិធីសាស្ត្រដែលមានបុព្វបទយឺត។ នេះជាការពិតសម្រាប់ទាំងការបែងចែក និងល្បឿននៃការងារ។ ម៉្យាងវិញទៀត ការអនុវត្តផែនទីដ៏ស្រស់ស្អាត និងឆើតឆាយដោយប្រើវិធីសាស្ត្រ LINQ ដែលមានបំណងសម្រាប់ការនេះគ្រប់ទីកន្លែងដែលអាចធ្វើទៅបាន ផ្ទុយទៅវិញ កាត់បន្ថយផលិតភាពយ៉ាងច្រើន។ ភាពខុសគ្នាគឺលំដាប់។ ទំនោរមិនផ្លាស់ប្តូរជាមួយនឹងលេខផ្សេងគ្នានៃការឆ្លងកាត់ ភាពខុសគ្នាតែមួយគត់គឺនៅក្នុងមាត្រដ្ឋាន។ ជាមួយនឹង LINQ វាមានល្បឿនយឺតជាង 4 ទៅ 200 ដង វាមានសំរាមច្រើននៅលើមាត្រដ្ឋានដូចគ្នា។

ធ្វើឱ្យទាន់សម័យ

ខ្ញុំ​មិន​ជឿ​ភ្នែក​ខ្ញុំ​ទេ ប៉ុន្តែ​សំខាន់​ជាង​នេះ​ទៅ​ទៀត មិត្ត​រួម​ការងារ​របស់​យើង​មិន​ជឿ​ភ្នែក​ខ្ញុំ ឬ​កូដ​របស់​ខ្ញុំ - Dmitry Tikhonov 0x1000000. ដោយបានពិនិត្យមើលដំណោះស្រាយរបស់ខ្ញុំពីរដង គាត់បានរកឃើញយ៉ាងត្រចះត្រចង់ និងបានចង្អុលបង្ហាញពីកំហុសដែលខ្ញុំខកខានដោយសារតែការផ្លាស់ប្តូរមួយចំនួននៅក្នុងការអនុវត្ត ពីដំបូងរហូតដល់ចុងក្រោយ។ បន្ទាប់ពីជួសជុលកំហុសដែលបានរកឃើញនៅក្នុងការដំឡើង Moq លទ្ធផលទាំងអស់បានធ្លាក់ចូលទៅក្នុងកន្លែង។ យោងតាមលទ្ធផលនៃការធ្វើតេស្តឡើងវិញនិន្នាការចម្បងមិនផ្លាស់ប្តូរ - LINQ នៅតែប៉ះពាល់ដល់ការអនុវត្តច្រើនជាងការឆ្លុះបញ្ចាំង។ ទោះយ៉ាងណាក៏ដោយ វាជាការប្រសើរណាស់ដែលការងារជាមួយការចងក្រងកន្សោមមិនត្រូវបានធ្វើដោយឥតប្រយោជន៍ទេ ហើយលទ្ធផលគឺអាចមើលឃើញទាំងក្នុងការបែងចែក និងពេលវេលាប្រតិបត្តិ។ ការបើកដំណើរការដំបូង នៅពេលដែលវាលឋិតិវន្តត្រូវបានចាប់ផ្តើម មានលក្ខណៈយឺតជាងសម្រាប់វិធីសាស្ត្រ "លឿន" ប៉ុន្តែបន្ទាប់មកស្ថានភាពបានផ្លាស់ប្តូរ។

នេះជាលទ្ធផលនៃការធ្វើតេស្តឡើងវិញ៖

សេចក្តីសន្និដ្ឋាន៖ នៅពេលប្រើការឆ្លុះបញ្ចាំងនៅក្នុងសហគ្រាស មិនចាំបាច់ងាកទៅរកល្បិចនោះទេ - LINQ នឹងស៊ីអស់ផលិតភាពកាន់តែច្រើន។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងវិធីសាស្រ្តផ្ទុកខ្ពស់ដែលទាមទារការបង្កើនប្រសិទ្ធភាព អ្នកអាចរក្សាទុកការឆ្លុះបញ្ចាំងក្នុងទម្រង់ជាអ្នកបង្កើតដំបូង និងអ្នកចងក្រងប្រតិភូ ដែលបន្ទាប់មកនឹងផ្តល់នូវតក្កវិជ្ជា "លឿន" ។ វិធីនេះអ្នកអាចរក្សាបានទាំងភាពបត់បែននៃការឆ្លុះបញ្ចាំង និងល្បឿននៃកម្មវិធី។

លេខកូដគោលមាននៅទីនេះ។ នរណាម្នាក់អាចពិនិត្យមើលពាក្យរបស់ខ្ញុំពីរដង៖
HabraReflectionTests

PS៖ កូដនៅក្នុងការធ្វើតេស្តប្រើ IoC ហើយនៅក្នុងគោលកំណត់វាប្រើការស្ថាបនាច្បាស់លាស់។ ការពិតគឺថានៅក្នុងការអនុវត្តចុងក្រោយខ្ញុំបានកាត់ចោលនូវកត្តាទាំងអស់ដែលអាចប៉ះពាល់ដល់ការអនុវត្ត និងធ្វើឱ្យលទ្ធផលមិនមានសម្លេងរំខាន។

PPS: សូមអរគុណដល់អ្នកប្រើប្រាស់ Dmitry Tikhonov @0x1000000 សម្រាប់ការរកឃើញកំហុសរបស់ខ្ញុំក្នុងការដំឡើង Moq ដែលប៉ះពាល់ដល់ការវាស់វែងដំបូង។ បើមិត្តអ្នកអានណាមានកម្មសិទ្ធគ្រប់គ្រាន់ សូម Like ផង។ បុរស​នោះ​ឈប់ បុរស​នោះ​អាន បុរស​នោះ​ពិនិត្យ​ពីរ​ដង ហើយ​ចង្អុល​បង្ហាញ​កំហុស។ ខ្ញុំ​គិត​ថា​នេះ​ជា​ការ​សក្តិសម​នៃ​ការ​គោរព​និង​អាណិតអាសូរ។

PPPS: សូមអរគុណដល់អ្នកអានដ៏ម៉ត់ចត់ដែលបានឈានដល់ផ្នែកខាងក្រោមនៃរចនាប័ទ្មនិងការរចនា។ ខ្ញុំសម្រាប់ឯកសណ្ឋាន និងភាពងាយស្រួល។ ការទូត​នៃ​បទ​បង្ហាញ​ទុក​ជា​ការ​ចង់​បាន​ច្រើន ប៉ុន្តែ​ខ្ញុំ​យក​ការ​រិះគន់​មក​ពិចារណា។ ខ្ញុំសុំបាញ់កាំជ្រួច។

ប្រភព: www.habr.com