সি # তে অসিঙ্ক / ব্যবহারের অপেক্ষার দিকনির্দেশগুলি কি ভাল আর্কিটেকচার এবং অ্যাবস্ট্রাকশন লেয়ারিংয়ের ধারণার বিরোধিতা করে না?

Question

এই প্রশ্নটি সি # ভাষা নিয়ে উদ্বেগ প্রকাশ করে তবে আমি এটি জাভা বা টাইপস্ক্রিপ্টের মতো অন্যান্য ভাষাগুলির কভার করার আশা করি।

মাইক্রোসফট .NET এ অ্যাসিক্রোনাস কলগুলি ব্যবহারের সর্বোত্তম অনুশীলনের প্রস্তাব দেয় । এই সুপারিশগুলির মধ্যে, আসুন দুটি বাছাই:

• অ্যাসিঙ্ক পদ্ধতির স্বাক্ষরটি পরিবর্তন করুন যাতে তারা টাস্ক বা টাস্ক <> (টাইপস্ক্রিপ্টে, এটি একটি প্রতিশ্রুতি <> হবে) ফেরত দেয়
• xxxAsync () দিয়ে শেষ হওয়ার জন্য অ্যাসিঙ্ক পদ্ধতির নাম পরিবর্তন করুন

এখন, অ্যাসিঙ্ক দ্বারা নিম্ন-স্তরের, সিঙ্ক্রোনাস উপাদানকে প্রতিস্থাপন করার সময়, এটি অ্যাপ্লিকেশনটির পুরো স্ট্যাককে প্রভাবিত করে। যেহেতু "সমস্ত উপায়ে" ব্যবহৃত হয় কেবলমাত্র async / প্রতীক্ষার ইতিবাচক প্রভাব রয়েছে, এর অর্থ হ'ল অ্যাপ্লিকেশনের প্রতিটি স্তরের স্বাক্ষর এবং পদ্ধতির নামগুলি অবশ্যই পরিবর্তন করতে হবে।

একটি ভাল আর্কিটেকচারে প্রায়শই প্রতিটি স্তরগুলির মধ্যে বিমূর্ততা স্থাপন করা জড়িত থাকে, যেমন অন্যের দ্বারা নিম্ন স্তরের উপাদানগুলি প্রতিস্থাপন করা উপরের স্তরের উপাদানগুলি অদৃশ্য। সি # তে বিমূর্ততা ইন্টারফেসের রূপ নেয়। যদি আমরা একটি নতুন, নিম্ন-স্তরের, অ্যাসিঙ্ক উপাদানটি প্রবর্তন করি, কল স্ট্যাকের প্রতিটি ইন্টারফেসকে হয় নতুন ইন্টারফেস দ্বারা পরিবর্তিত বা প্রতিস্থাপন করা দরকার। কোনও বাস্তবায়নকারী শ্রেণিতে যেভাবে সমস্যার সমাধান হয় (অ্যাসিঙ্ক বা সিঙ্ক) তা আর কলকারীদের কাছে গোপন (বিমূর্ত) হয় না। ফোনকারীদের এটি সিঙ্ক বা অ্যাসিঙ্ক কিনা তা জানতে হবে।

"ভাল আর্কিটেকচার" নীতিগুলির সাথে বিরোধী সেরা অভ্যাসগুলি কি অ্যাসিঙ্ক / অপেক্ষা করছে না?

এর অর্থ কি এই যে প্রতিটি ইন্টারফেসের (আইইনিউমারেবল, আইডাটাএ্যাক্সেসলায়ার বলুন) তাদের অ্যাসিঙ্ক কাউন্টার পার্টের (আইএসিএনসিউইনামেবল, আইএসিএনসিডিটাএ্যাকসেসলায়ার) এর দরকার যেমন এ্যাসিঙ্ক নির্ভরতাগুলিতে স্যুইচ করার সময় এগুলি স্ট্যাকে প্রতিস্থাপন করা যেতে পারে?

আমরা যদি সমস্যাটিকে আরও খানিকটা ধাক্কা দিই, তবে প্রতিটি পদ্ধতিকে async (কোনও টাস্ক <> বা প্রতিশ্রুতি <> ফেরত পাঠানো) হিসাবে গ্রহণ করা সহজ হবে না, এবং পদ্ধতিগুলি না আসলে যখন তারা আসনক কলগুলি সিঙ্ক্রোনাইজ করে to ASYNC? ভবিষ্যতের প্রোগ্রামিং ভাষা থেকে এটি কি আশা করা যায়?

Comments

যদিও এটি দুর্দান্ত আলোচনার প্রশ্নের মতো মনে হচ্ছে, আমি মনে করি এটি এখানে খুব বেশি মতামত ভিত্তিক উত্তর দেওয়া উচিত।

— ইওফোরিক

@ ইউফোরিক: আমি মনে করি যে এখানে আঁকানো সমস্যাটি সি # নির্দেশিকাগুলির চেয়েও গভীরতর হয়েছে, এটি কেবলমাত্র একটি লক্ষণ যে অ্যাপ্লিকেশনটির কিছু অংশ অ্যাসিঙ্ক্রোনাস আচরণে পরিবর্তনের ফলে সামগ্রিক ব্যবস্থায় অ-স্থানীয় প্রভাব থাকতে পারে। সুতরাং আমার অন্ত্রটি আমাকে বলছে প্রযুক্তিগত তথ্যের ভিত্তিতে এর জন্য অবশ্যই একটি অ-মতামত উত্তর থাকতে হবে। অতএব, আমি এখানে সবাইকে উত্সাহ দিচ্ছি খুব শীঘ্রই এই প্রশ্নটি বন্ধ না করার পরিবর্তে আসুন আমরা কী উত্তর আসবে তা অপেক্ষা করি (এবং যদি তারা খুব মতামতযুক্ত হয় তবে আমরা এখনও বন্ধ হওয়ার পক্ষে ভোট দিতে পারি)।

— ডক ব্রাউন 10

@ ডকব্রাউন আমার মনে হয় এখানে গভীরতর প্রশ্নটি হচ্ছে "সিস্টেমের কিছু অংশকে কি সিঙ্ক্রোনাস থেকে অ্যাসিনক্রোনাসে পরিবর্তন করা যায় যার উপর নির্ভর করে এমন অংশগুলিও পরিবর্তিত হতে পারে?" আমি মনে করি এর উত্তর পরিষ্কার "না"। সেক্ষেত্রে আমি দেখতে পাই না "ভাল আর্কিটেকচার এবং লেয়ারিংয়ের ধারণা" এখানে কীভাবে প্রয়োগ হয়।

— ইওফোরিক

@ ইউফোরিক: অ-মতামতযুক্ত উত্তরের জন্য ভাল ভিত্তি মত শোনাচ্ছে ;-)

— ডক ব্রাউন

@ গেরম্যান: কারণ সি #, অনেকগুলি ভাষার মতো, কেবলমাত্র রিটার্নের টাইপের ভিত্তিতে ওভারলোডিং করতে পারে না। আপনি সমাপ্ত পদ্ধতিগুলির সাথে সমাপ্ত হবেন যাঁদের সিঙ্ক সমকক্ষগুলির মতো একই স্বাক্ষর রয়েছে (সকলেই নিতে পারে না CancellationToken, এবং যারা ডিফল্ট সরবরাহ করতে চায়)। বিদ্যমান সিঙ্ক পদ্ধতিগুলি (এবং সক্রিয়ভাবে সমস্ত কোড ভঙ্গ করা) অপসারণ একটি সুস্পষ্ট নন-স্টার্টার।

— জেরোইন মোস্টার্ট

Answer 1

আপনার ফাংশনটি কী রঙ?

আপনি বব নাইস্ট্রমের হ'ল কালার ইজ আপনার ফাংশন ^1-এ আগ্রহী হতে পারেন ।

এই নিবন্ধে, তিনি একটি কাল্পনিক ভাষা বর্ণনা করেছেন যেখানে:

• প্রতিটি ফাংশনের একটি রঙ থাকে: নীল বা লাল।
• একটি লাল ফাংশন নীল বা লাল ফাংশনগুলি কল করতে পারে, কোনও সমস্যা নেই।
• একটি নীল ফাংশন কেবল নীল ফাংশনগুলিকে কল করতে পারে।

কল্পিত হলেও, প্রোগ্রামিং ভাষাগুলিতে এটি নিয়মিত ঘটে:

• সি ++ এ, "কনস্ট" পদ্ধতিটি কেবল অন্য "কনস্ট" পদ্ধতিগুলিতে কল করতে পারে this।
• হাসকেলে, একটি নন-আইও ফাংশন কেবল অ-আইও ফাংশনগুলিকে কল করতে পারে।
• সি # তে, একটি সিঙ্ক ফাংশন কেবল সিঙ্ক ফাংশন ^{2 কে} কল করতে পারে ।

আপনি যেমন বুঝতে পেরেছেন, এই নিয়মের কারণে, লাল ফাংশনগুলি কোড বেসের চারদিকে ছড়িয়ে পড়ে। আপনি একটি sertোকান এবং অল্প অল্প করেই এটি পুরো কোড বেসটি কলোনাইজ করে।

¹ বব নাইস্ট্রম, ব্লগিং ছাড়াও ডার্ট টিমেরও একটি অংশ এবং এই ছোট্ট ক্র্যাফটিং ইন্টারপ্রেটারদের সিরি লিখেছেন; কোনও প্রোগ্রামিং ভাষা / সংকলক afficionado জন্য অত্যন্ত প্রস্তাবিত।

² একেবারে সত্য নয়, আপনি কোনও অ্যাসিঙ্ক ফাংশনটি কল করতে পারেন এবং এটি ফিরে না আসা পর্যন্ত অবরুদ্ধ করে দিতে পারেন, তবে ...

ভাষার সীমাবদ্ধতা

এটি মূলত একটি ভাষা / রান-সময় সীমাবদ্ধতা।

এম এর সাথে ভাষা: এন থ্রেডিং, উদাহরণস্বরূপ, এরলং এবং গোয়ের মতো asyncফাংশনগুলি নেই: প্রতিটি ফাংশন সম্ভাব্য অ্যাসিঙ্ক হয় এবং এর "ফাইবার" কেবল স্থগিত হয়ে যায়, অদলবদল হয়ে যায় এবং আবার প্রস্তুত হয়ে গেলে এটিকে আবার সরিয়ে নেওয়া হবে।

সি # 1: 1 থ্রেডিং মডেল নিয়ে গিয়েছিল এবং অতএব ঘটনাক্রমে থ্রেডগুলি ব্লক করা এড়ানোর জন্য ভাষায় সিনক্রোনিকাইটি উপস্থাপিত করার সিদ্ধান্ত নিয়েছে।

ভাষার সীমাবদ্ধতার উপস্থিতিতে কোডিং নির্দেশিকা মানিয়ে নিতে হয়।

Comments

আইও ফাংশনগুলির প্রসারণের প্রবণতা রয়েছে তবে অধ্যবসায়ের সাথে আপনি তাদের কোডের প্রবেশ পয়েন্টগুলির নিকটে (কল করার সময় স্ট্যাকের মধ্যে) বেশিরভাগ এগুলি আলাদা করতে পারেন। আপনি এই ফাংশনগুলি আইও ফাংশনগুলি কল করে এবং তারপরে অন্যান্য ফাংশনগুলি থেকে আউটপুট প্রক্রিয়া করে এবং এটি আরও আইওয়ের জন্য প্রয়োজনীয় কোনও ফলাফল ফিরিয়ে দিয়ে আপনি এটি করতে পারেন। আমি দেখতে পাচ্ছি যে এই স্টাইলটি আমার কোড বেসগুলিকে পরিচালনা এবং এর সাথে কাজ করতে আরও সহজ করে তোলে। আমি ভাবছি সিনক্রোনসিটির কোনও বাস্তবায়ন আছে কিনা।

— jpmc26

"এম: এন" এবং "1: 1" থ্রেডিংয়ের অর্থ কী?

— ক্যাপ্টেন ম্যান

@ ক্যাপিটম্যান: 1: 1 থ্রেডিংয়ের অর্থ একটি ওএস থ্রেডে একটি অ্যাপ্লিকেশন থ্রেড ম্যাপিং, এটি সি, সি ++, জাভা বা সি # এর মতো ভাষাগুলিতে। বিপরীতে, এম: এন থ্রেডিং মানে এন অ্যাপ্লিকেশন থ্রেডগুলিকে এন ওএস থ্রেডগুলিতে ম্যাপিং করা; গো এর ক্ষেত্রে, অ্যাপ্লিকেশন থ্রেডকে "গোরোটিন" বলা হয়, এরলংয়ের ক্ষেত্রে এটি "অভিনেতা" নামে পরিচিত, এবং আপনি তাদের "গ্রিন থ্রেড" বা "ফাইবার" হিসাবে শুনে থাকতে পারেন। তারা সমান্তরালতার প্রয়োজন ছাড়াই সম্মতি প্রদান করে। দুর্ভাগ্যক্রমে এই বিষয়টির উইকিপিডিয়া নিবন্ধটি তুলনামূলক কম।

— ম্যাথিউ এম

এটি কিছুটা সম্পর্কিত তবে আমি এই "ফাংশন রঙ" ধারণাটি এমন ফাংশনগুলির ক্ষেত্রেও প্রযোজ্য যা ব্যবহারকারীদের ইনপুট থেকে ব্লক করে, উদাহরণস্বরূপ, মডেল ডায়ালগ বাক্স, বার্তা বাক্স, কনসোল I / O এর কিছু ফর্ম ইত্যাদি যা সরঞ্জামগুলি কাঠামো শুরু থেকেই ছিল।

— জুন

@MatthieuM। সি # এর প্রতি ওএস থ্রেডের জন্য একটি অ্যাপ্লিকেশন থ্রেড নেই এবং কখনও করেনি। এটি খুবই সুস্পষ্ট যখন আপনি নেটিভ কোড ইন্টারঅ্যাক্ট করছেন, এবং বিশেষত সুস্পষ্ট যখন মাইক্রোসফট SQL এর যে চলছে। এবং অবশ্যই, সমবায় রুটিনগুলি সর্বদা সম্ভব ছিল (এবং এর সাথে আরও সহজ async); প্রকৃতপক্ষে, প্রতিক্রিয়াশীল UI তৈরির জন্য এটি একটি দুর্দান্ত সাধারণ প্যাটার্ন ছিল। এটি কি এরলংয়ের মতোই সুন্দর ছিল? নাঃ। তবে এটি এখনও সি এর থেকে অনেক দূরের কান্না

— লুয়ান

Answer 2

আপনি ঠিক বলেছেন এখানে একটি বৈপরীত্য রয়েছে, তবে এটি "সেরা অনুশীলনগুলি" খারাপ হওয়া নয়। এটি কারণ অ্যাসিনক্রোনাস ফাংশন মূলত একটি সিঙ্ক্রোনাসের চেয়ে আলাদা আলাদা জিনিস করে। ফলাফলটি তার নির্ভরতা (সাধারণত কিছু আইও) থেকে অপেক্ষার পরিবর্তে এটি মূল ইভেন্ট লুপ দ্বারা পরিচালিত একটি টাস্ক তৈরি করে। এটি কোনও পার্থক্য নয় যা বিমূর্তনের অধীনে ভালভাবে লুকানো থাকতে পারে।

Comments

উত্তরটি এই আইএমওর মতো সহজ। একটি সিঙ্ক্রোনাস এবং অ্যাসিক্রোনাস প্রক্রিয়ার মধ্যে পার্থক্য একটি বাস্তবায়নের বিশদ নয় - এটি একটি শব্দার্থগতভাবে পৃথক চুক্তি।

— পিঁপিতে পি

@ অ্যান্টপি: আমি একমত নই যে এটি এত সহজ; এটি সি # ভাষায় ভেসে উঠেছে, তবে গো ভাষায় নয়। সুতরাং এটি অ্যাসিনক্রোনাস প্রক্রিয়াগুলির অন্তর্নিহিত সম্পত্তি নয়, প্রদত্ত ভাষায় অ্যাসিক্রোনাস প্রসেসগুলি কীভাবে মডেল করা হয় তা বিষয়।

— ম্যাথিউ এম।

@MatthieuM। হ্যাঁ, তবে আপনি চাইলে asyncসিঙ্ক্রোনাস চুক্তিও সরবরাহ করতে সি # তে পদ্ধতি ব্যবহার করতে পারেন । পার্থক্যটি কেবল হ'ল গো ডিফল্ট হিসাবে অ্যাসিনক্রোনাস হয় যখন সি # ডিফল্টর সাথে সিঙ্ক্রোনাস হয়। asyncআপনাকে দ্বিতীয় প্রোগ্রামিং মডেল দেয় - async এটি বিমূর্ততা (এটি আসলে কী রানটাইম, টাস্ক শিডিয়ুলার, সিঙ্ক্রোনাইজেশন প্রসঙ্গে, প্রতীক্ষার বাস্তবায়নের উপর নির্ভর করে ...)।

— লুয়ান

Answer 3

অ্যাসিঙ্ক্রোনাস পদ্ধতিটি সিঙ্ক্রোনাসের চেয়ে আলাদা আচরণ করে, কারণ আমি নিশ্চিত যে আপনি সচেতন। রানটাইমের সময়, অ্যাসিঙ্ক কলকে একটি সিঙ্ক্রোনাসে রূপান্তর করা তুচ্ছ, তবে বিপরীতটি বলা যায় না। সুতরাং লজিকটি তখন হয়ে যায়, কেন আমরা প্রয়োজনীয় প্রতিটি পদ্ধতির async পদ্ধতি তৈরি করি না এবং কলকারীকে প্রয়োজনীয় হিসাবে একটি রূপান্তরকারী পদ্ধতিতে "রূপান্তর" করতে দেয়?

এক অর্থে এটি এমন একটি পদ্ধতি থাকার মতো যা ব্যতিক্রম ছোঁড়ে এবং অন্যটি যা "নিরাপদ" এবং ত্রুটির ক্ষেত্রে এমনকি ছুঁড়ে ফেলবে না। কোডারটি কোন সময়ে এই পদ্ধতিগুলি সরবরাহ করার জন্য অত্যধিক হচ্ছে যা অন্যথায় একে অন্যকে রূপান্তরিত করা যেতে পারে?

এর মধ্যে দুটি চিন্তাভাবনা বিদ্যালয় রয়েছে: একটি হ'ল একাধিক পদ্ধতি তৈরি করা, প্রত্যেকে একে অপরকে বেসরকারী পদ্ধতি হিসাবে কল করা যাকে অবিচ্ছিন্ন হওয়ার মতো আচরণে alচ্ছিক প্যারামিটার বা ছোটখাটো পরিবর্তন সরবরাহ করার সম্ভাবনা দেয়। অন্যটি হ'ল প্রয়োজনীয় সংশোধন করার জন্য ইন্টারফেসের পদ্ধতিগুলি ন্যূনতম করা যাকে কলিংয়ের হাতে রেখে নিজেই প্রয়োজনীয় পরিবর্তনগুলি সম্পাদন করে।

আপনি যদি প্রথম বিদ্যালয়ের হন তবে প্রতিটি কল দ্বিগুণ হওয়া এড়াতে সিঙ্ক্রোনাস এবং অ্যাসিনক্রোনাস কলগুলিতে শ্রেণি উত্সর্গ করার জন্য একটি নির্দিষ্ট যুক্তি রয়েছে। মাইক্রোসফ্ট এই চিন্তাভাবনাটির পক্ষে, এবং কনভেনশন অনুসারে মাইক্রোসফ্টের অনুকূলে থাকা স্টাইলের সাথে সামঞ্জস্য রাখার জন্য আপনারও একটি অ্যাসিঙ্ক সংস্করণ থাকতে হবে, একইভাবে ইন্টারফেসগুলি প্রায় সবসময় একটি "আই" দিয়ে শুরু হয়। আমাকে জোর দিয়ে দিন যে এটি ভুল নয় , কারণ, কোনও প্রকল্পে একটি "ধারাবাহিক শৈলী" রাখার চেয়ে এটি "সঠিক উপায়ে" না করাই ভাল এবং আপনি যে প্রকল্পে যুক্ত হন সেই উন্নয়নের জন্য আমূল পরিবর্তন করে change

এটি বলেছিল, আমি দ্বিতীয় বিদ্যালয়ের পক্ষে যাচ্ছি, যা ইন্টারফেসের পদ্ধতিগুলি হ্রাস করতে হবে। যদি আমি মনে করি কোনও পদ্ধতিকে একটি অ্যাসিঙ্ক্রোনাস উপায়ে বলা যেতে পারে তবে আমার জন্য পদ্ধতিটি অ্যাসিক্রোনাস। অগ্রসর হওয়ার আগে সেই কাজটি শেষ হওয়ার জন্য অপেক্ষা করা হবে কিনা তা কলার স্থির করতে পারেন। যদি এই ইন্টারফেসটি কোনও লাইব্রেরির ইন্টারফেস হয় তবে আপনার অবচয় বা সমন্বয় করার জন্য যে পদ্ধতিগুলি প্রয়োজন সেগুলি হ্রাস করার জন্য এইভাবে এটি করা আরও যুক্তিসঙ্গত। যদি ইন্টারফেসটি আমার প্রকল্পের অভ্যন্তরীণ ব্যবহারের জন্য হয়, তবে আমি সরবরাহিত পরামিতিগুলির জন্য আমার সমস্ত প্রকল্পের প্রতিটি প্রয়োজনীয় কলের জন্য একটি পদ্ধতি যুক্ত করব এবং কোনও "অতিরিক্ত" পদ্ধতি নেই, এবং তারপরেও, কেবল যদি পদ্ধতিটির আচরণ ইতিমধ্যে আবৃত না হয় if একটি বিদ্যমান পদ্ধতি দ্বারা

তবে, এই ক্ষেত্রের অনেক কিছুর মতো এটিও মূলত বিষয়গত j উভয় পদ্ধতির তাদের পক্ষে মতামত রয়েছে। মাইক্রোসফ্ট ভেরিয়েবল নামের শুরুতে টাইপের নির্দেশক অক্ষর যুক্ত করার কনভেনশনও শুরু করে এবং "এম_" এটি সদস্য হিসাবে চিহ্নিত করার জন্য পরিবর্তনশীল নামের মতো অগ্রণী হয় m_pUser। আমার বক্তব্যটি হ'ল মাইক্রোসফ্টও অপূর্ণ নয়, এবং ভুলও করতে পারে।

এটি বলেছে, যদি আপনার প্রকল্পটি এই অ্যাসিঙ্ক কনভেনশনটি অনুসরণ করে তবে আমি আপনাকে এটি সম্মান করার এবং স্টাইলটি চালিয়ে যাওয়ার পরামর্শ দিচ্ছি। এবং শুধুমাত্র একবার আপনাকে নিজের প্রকল্প দেওয়া হলে আপনি এটি উপযুক্তভাবে দেখতে পারেন।

Comments

"রানটাইমের সময়, অ্যাসিঙ্ক কলকে একটি সিঙ্ক্রোনাসে রূপান্তর করা তুচ্ছ" আমি নিশ্চিত নই যে এটি ঠিক তাই। .NET- এ, .Wait()পদ্ধতি এবং পছন্দ ব্যবহার করা নেতিবাচক পরিণতি ঘটাতে পারে এবং জেএসে, যতদূর আমি জানি, এটি মোটেই সম্ভব নয়।

— সর্বোচ্চ 630

@ সর্বাধিক 30৩০ আমি বলিনি যে বিবেচনার জন্য সাম্প্রতিক সমস্যা নেই, তবে এটি প্রাথমিকভাবে যদি একটি সিনক্রোনাস কাজ হয় তবে সম্ভাবনা রয়েছে যে এটি অচলাবস্থা তৈরি করছে না। এটি বলেছিল, তুচ্ছ অর্থ "সিঙ্ক্রোনাসে রূপান্তর করতে এখানে ডাবল ক্লিক করুন" না। জেএসে, আপনি একটি প্রতিশ্রুতি উদাহরণ ফিরিয়ে দেন এবং এটির জন্য সমাধান কল করুন।

— নীল

হাঁ তার সম্পূর্ণই গাধা ব্যাথা সিঙ্ক ফিরে ASYNC রূপান্তর করতে

— ইওয়ান

@ নীল জাভাস্ক্রিপ্টে, এমনকি যদি আপনি কল করেন Promise.resolve(x)এবং তারপরে কলব্যাকগুলি যুক্ত করেন তবে এই কলব্যাকগুলি তত্ক্ষণাত কার্যকর করা হবে না।

— নিকল

@ নিল যদি কোনও ইন্টারফেস অ্যাসিক্রোনাস পদ্ধতি উদ্ঘাটিত করে, টাস্কে অপেক্ষা করা কোনও অচলাবস্থা তৈরি করবে না এমন আশা করা ভাল ধারণা নয়। ইন্টারফেসের জন্য এটি প্রদর্শিত পদ্ধতি স্বাক্ষরের মধ্যে প্রকৃতির সিঙ্ক্রোনাস হ'ল এটি আরও অনেক ভাল, ডকুমেন্টেশনের প্রতিশ্রুতি যা পরবর্তী সংস্করণে পরিবর্তিত হতে পারে than

— কার্ল ওয়ালশ

Answer 4

আসুন কল্পনা করুন এমন একটি উপায় রয়েছে যা আপনাকে অ্যাসিঙ্ক পদ্ধতিতে তাদের স্বাক্ষর পরিবর্তন না করে কল করতে সক্ষম করে।

এটি সত্যিই দুর্দান্ত হবে এবং কেউ তাদের নাম পরিবর্তন করার পরামর্শ দিবে না।

তবে, আসল অ্যাসিনক্রোনাস ফাংশন, কেবলমাত্র অন্য একটি অ্যাসিঙ্ক ফাংশনের জন্য অপেক্ষা করে না, তবে সর্বনিম্ন স্তরের তাদের অ্যাসিঙ্ক প্রকৃতির সাথে নির্দিষ্ট কিছু কাঠামো রয়েছে। যেমন

public class HTTPClient
{
    public HTTPResponse GET()
    {
        //send data
        while(!timedOut)
        {
            //check for response
            if(response) { 
                this.GotResponse(response); 
            }
            this.YouCanWait();
        }
    }

    //tell calling code that they should watch for this event
    public EventHander GotResponse
    //indicate to calling code that they can go and do something else for a bit
    public EventHander YouCanWait;
}

এই দুটি বিট তথ্য যা কলিং কোডটি কোডটিকে একটি অ্যাসিঙ্ক উপায়ে চালাতে যাতে জিনিস পছন্দ করে Taskএবং asyncএনক্যাপসুলেট করে।

অ্যাসিঙ্ক্রোনাস ফাংশন করার একাধিক উপায় রয়েছে, async Taskরিটার্ন টাইপের মাধ্যমে সংকলকটিতে কেবল একটি প্যাটার্ন তৈরি করা হয়েছে যাতে আপনাকে ম্যানুয়ালি ইভেন্টগুলি সংযুক্ত করতে না হয়

Answer 5

আমি কম সি # নেস ফ্যাশন এবং আরও জেনেরিকের মূল পয়েন্টটি সম্বোধন করব:

"ভাল আর্কিটেকচার" নীতিগুলির সাথে বিরোধী সেরা অভ্যাসগুলি কি অ্যাসিঙ্ক / অপেক্ষা করছে না?

আমি বলব যে এটি আপনার API এর ডিজাইনে আপনার পছন্দ এবং ব্যবহারকারীকে আপনি কী দিয়েছেন তার উপর নির্ভর করে।

আপনি যদি চান আপনার API এর একটি ফাংশনটি কেবলমাত্র async হয় নামকরণ কনভেনশন অনুসরণ করার ক্ষেত্রে খুব আগ্রহ নেই। কেবল সর্বদা টাস্ক <> / প্রতিশ্রুতি <> / ভবিষ্যত <> / ... রিটার্নের ধরণ হিসাবে ফিরিয়ে দিন এটি স্ব স্ব নথিভুক্ত। যদি একটি সিঙ্ক্রোনাইজ উত্তর চায়, তবে তিনি অপেক্ষা করে তা করতে সক্ষম হবেন তবে যদি তিনি সর্বদা এটি করেন তবে এটি কিছুটা বয়লারপ্লেট তৈরি করে।

তবে আপনি যদি কেবল আপনার এপিআই সিঙ্ক তৈরি করেন তবে এর অর্থ হ'ল কোনও ব্যবহারকারী যদি এটি অ্যাসিঙ্ক হিসাবে চায় তবে তাকে তার অ্যাসিঙ্ক অংশটি নিজেই পরিচালনা করতে হবে।

এটি বেশ কিছু অতিরিক্ত কাজ করতে পারে, তবে এটি ব্যবহারকারীকে কতটা সমকালীন কলটি দেয়, সময়সীমা শেষ করে, পুনরায় চেষ্টা করে এবং আরও অনেক কিছু নিয়ন্ত্রণ করতে পারে।

একটি বিশাল এপিআই সহ একটি বৃহত সিস্টেমে, তাদের বেশিরভাগটি ডিফল্টরূপে সিঙ্ক হওয়ার জন্য প্রয়োগ করা আপনার API এর প্রতিটি অংশকে স্বাধীনভাবে পরিচালনার চেয়ে সহজ এবং আরও কার্যকর হতে পারে, বিশেষত যদি তারা রিসোর্সগুলি ভাগ করে দেয় (ফাইল সিস্টেম, সিপিইউ, ডাটাবেস, ...)।

সবচেয়ে জটিল অংশগুলির জন্য, আপনি পুরোপুরি আপনার API এর একই অংশের দুটি বাস্তবায়ন করতে পারেন, একটি সিঙ্ক্রোনাস হ্যান্ডি স্টাফ করছে, একটি সিঙ্ক্রোনাসের উপর নির্ভরশীল এক অ্যাসিক্রোনাস হ্যান্ড হ্যান্ড স্টাফ এবং কেবল সামঞ্জস্য, লোড, সময়সীমা এবং পুনরায় চেষ্টা পরিচালনা করে ।

হতে পারে যে অন্য কেউ তার সাথে তার অভিজ্ঞতা ভাগ করে নিতে পারে কারণ এই জাতীয় সিস্টেমগুলির সাথে আমার অভিজ্ঞতা নেই।

Comments

@ মিরাল আপনি উভয় সম্ভাবনায় "একটি সিঙ্ক পদ্ধতি থেকে একটি অ্যাসিঙ্ক পদ্ধতি কল করুন" ব্যবহার করেছেন।

— অ্যাড্রিয়ান র্যাগগ

@ অ্যাড্রিয়ানরাগ তাই আমি করেছি; আমার মস্তিষ্কের অবশ্যই রেসের অবস্থা ছিল। আমি এটা ঠিক করব.

— মিরাল

এটি অন্য উপায়ে; একটি সিঙ্ক পদ্ধতি থেকে একটি অ্যাসিঙ্ক পদ্ধতি কল করা তুচ্ছ, তবে একটি অ্যাসিঙ্ক পদ্ধতি থেকে একটি সিঙ্ক পদ্ধতি কল করা অসম্ভব। (এবং যেখানে জিনিসগুলি সম্পূর্ণরূপে বিচ্ছিন্ন হয় তখন যখন কেউ যেহেতু পরেরটি করার চেষ্টা করে, যা অচলাবস্থার দিকে পরিচালিত করতে পারে)) সুতরাং যদি আপনাকে কোনওটি বেছে নিতে হয় তবে ডিফল্ট হিসাবে অ্যাসিঙ্কটিই সেরা পছন্দ choice দুর্ভাগ্যক্রমে এটি আরও কঠিন পছন্দ, কারণ একটি অ্যাসিঙ্ক বাস্তবায়ন কেবল অ্যাসিঙ্ক পদ্ধতিতে কল করতে পারে।

— মিরাল

(এবং এর মাধ্যমে অবশ্যই আমি একটি ব্লক করা সিঙ্ক পদ্ধতিটি বোঝাতে চাইছি as ইউআই প্রসঙ্গে নয় - তবে কোনও লক বা আই / ও বা অন্য কোনও অপারেশনের জন্য অলসভাবে অপেক্ষা করা কলগুলি অবরুদ্ধ করা খারাপ ধারণা))

— মিরাল