জিইউআই প্রোগ্রামিংয়ে থ্রেড সুরক্ষা নিশ্চিত করা কেন কলারের দায়িত্ব?


37

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

কেন এমন হয়? ইভেন্ট ডিসপ্যাচ থ্রেডটি এমভিসি / এমভিপি / এমভিভিএম- এ দৃশ্য দেখার উদ্বেগ ; যে কোন জায়গায় হ্যান্ডেল করতে কিন্তু দৃশ্য একটি সৃষ্টি আঁট কাপলিং দৃশ্য বাস্তবায়ন মধ্যে, এবং যে দৃশ্য বাস্তবায়ন এর থ্রেডিং মডেল।

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

সুতরাং, আমি মনে করি আমার দুটি প্রশ্ন রয়েছে:

  1. ইউআই উপাদান উপাদান থ্রেড সুরক্ষা নিশ্চিত করা কেন কলারের দায়িত্ব? উপরে আমার যুক্তিতে ত্রুটি কোথায়?
  2. এই থ্রেড সুরক্ষা উদ্বেগের শিথিল সংযোগ পেতে আমি কীভাবে আমার অ্যাপ্লিকেশনটি ডিজাইন করতে পারি, তবুও যথাযথভাবে থ্রেড-নিরাপদ থাকতে পারি?

আমি "কলার দায়বদ্ধ" বলতে কী বোঝাতে চেয়েছি তা বোঝাতে আমাকে কিছু এমসিসিই জাভা কোড যুক্ত করুন (এখানে আরও কিছু ভাল অভ্যাস রয়েছে যা আমি করছি না তবে আমি যতটা সম্ভব ন্যূনতম হওয়ার উদ্দেশ্যে চেষ্টা করছি):

কলার দায়বদ্ধ:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        view.setData(data);
      }
    });
  }
}
public class View {
  void setData(Data data) {
    component.setText(data.getMessage());
  }
}

দায়বদ্ধ হওয়া দেখুন:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    view.setData(data);
  }
}
public class View {
  void setData(Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        component.setText(data.getMessage());
      }
    });
  }
}

1: post পোস্টের লেখকের স্যুইচ অন স্ট্যাক ওভারফ্লোতে সর্বাধিক ট্যাগ স্কোর রয়েছে। তিনি এটিকে পুরো জায়গাতেই বলছেন এবং আমি অন্যান্য স্থানেও এটিকে কলারের দায়িত্ব বলে দেখেছি।


1
এহ, পারফরম্যান্স আইএমএইচও। এই ইভেন্টগুলির পোস্টিং নিখরচায় আসে না, এবং অ-তুচ্ছ অ্যাপগুলিতে আপনি তাদের সংখ্যা হ্রাস করতে চান (এবং নিশ্চিত করুন যে কোনওটি খুব বেশি বড় নয়) তবে এই উপস্থাপনায় সংক্ষিপ্তকরণ / ঘনত্ব যৌক্তিকভাবে করা উচিত।
Ordous

1
@ আরডস আপনি এখনও নিশ্চিত করতে পারেন যে থ্রেড হ্যান্ডঅফটি দর্শন করার সময় পোস্টিংগুলি ন্যূনতম।
durron597

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

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

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

উত্তর:


22

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

অন্য কথায়, আপনি যদি ইভেন্ট ইভেন্টের সারি মডেলের উপরে একটি মাল্টিথ্রেডেড ফেইসড রাখার চেষ্টা করেন তবে বিমূর্ততাটি মাঝে মধ্যে অ-স্পষ্ট উপায়ে ফাঁস হয়ে যায় যা ডিবাগ করা অত্যন্ত কঠিন। দেখে মনে হচ্ছে এটি কাগজে কাজ করবে তবে উত্পাদন শেষ হয়ে যাবে।

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

মনে রাখবেন যে এই ধরণের সমস্যাগুলি সমস্ত জিইউআই সরঞ্জামদণ্ডগুলিতে সর্বজনীন। আপনার উপস্থাপক / নিয়ন্ত্রকের ইভেন্ট প্রেরণের মডেলটিকে ধরে রেখে কেবলমাত্র একটি নির্দিষ্ট জিইআইআই সরঞ্জামকিটের সম্মতিযুক্ত মডেলটি আপনাকে দৃ tight়ভাবে সংযুক্ত করে না, এটি আপনাকে তাদের সকলের সাথে সংযুক্ত করে । ইভেন্টের সারিবদ্ধ ইন্টারফেসটি বিমূর্ত করার পক্ষে এতটা কঠিন হওয়া উচিত নয়।


25

কারণ জিইউআই লাইব থ্রেডকে নিরাপদ করা একটি বিশাল মাথাব্যথা এবং একটি বাধা।

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

একটি লক কৌশল যে রুট উইন্ডোতে লক করে না (বিবাদের অনেক কারণ হবে) উদ্ভাবন হয় কঠিন । তাত্ক্ষণিক অচলাবস্থা অর্জনের জন্য অন্য থ্রেডকে উপরে নীচে লক করার সময় নীচে লক করা।

এবং বর্তমান থ্রেডটি প্রতিবার গুই থ্রেড কিনা তা পরীক্ষা করা ব্যয়বহুল এবং গুইয়ের সাথে আসলে কী ঘটছে তা নিয়ে বিভ্রান্তি সৃষ্টি করতে পারে, বিশেষত যখন আপনি রিড আপডেট আপডেট লেখার ক্রমটি করছেন। দৌড়াদৌড়ি এড়াতে এর জন্য ডেটাতে লক থাকা দরকার।


1
মজার বিষয় হল, আমি এই আপডেটগুলির জন্য সারিবদ্ধ কাঠামো রেখে এই সমস্যাটি সমাধান করি যা আমি লিখেছিলাম যে থ্রেড হ্যান্ডঅফ পরিচালনা করে।
durron597

2
@ durron597: এবং ইউআই এর বর্তমান অবস্থার উপর নির্ভর করে আপনার কোনও আপডেট কখনই নেই অন্য থ্রেডের প্রভাব পড়তে পারে? তাহলে এটি কাজ করতে পারে।
উত্সাহক

আপনার কেন নেস্টেড লক লাগবে? শিশু উইন্ডোতে বিশদ কাজ করার সময় আপনাকে কেন পুরো রুট উইন্ডোটি লক করতে হবে? ডান ক্রমে একচেটিয়া পদ্ধতিতে মাল্টলিপল লকগুলি লক করার জন্য লক অর্ডার হ'ল সমাধানযোগ্য সমস্যা (শীর্ষে-নীচে বা নীচের অংশে, তবে
পছন্দটিকে

1
রুটযুক্ত @ এসএমএলটাররা আমার বর্তমান উইন্ডোটি বোঝায়। সমস্ত লক অর্জন করার জন্য আপনাকে পদাশক্তি অর্জন এবং আনলকিং (আপনি কেবল উপরে-ডাউনকে লক করতে হবে) তা নিশ্চিত করার জন্য প্রতিটি কন্টেইনারটি লক করতে হবে এমন হায়ারার্কি চালিয়ে যেতে হবে এবং তারপরে আশা করি এটির কোনও পরিবর্তন হয়নি hope আপনি রুট উইন্ডোটি পাওয়ার পরে আপনি লকটি টপ-ডাউন করেন।
ratchet freak

@ratchetfreak: আপনি যে শিশুটিকে লক করার চেষ্টা করছেন সেটি যদি আপনি লক করার সময় অন্য থ্রেড দ্বারা সরানো হয় তবে এটি কিছুটা দুর্ভাগ্যজনক তবে লক করার ক্ষেত্রে প্রাসঙ্গিক নয়। আপনি কেবল এমন কোনও জিনিসে অপারেট করতে পারবেন না যা অন্য থ্রেড সরিয়ে ফেলেছে। তবে অন্য থ্রেড কেন আপনার থ্রেডটি এখনও ব্যবহার করছে এমন অবজেক্ট / উইন্ডোজ অপসারণ করছে? এটি কোনও ইউআই-তে নয়, কোনও দৃশ্যেও ভাল নয়।
এমএসএলটাররা 3'15

17

থ্রেডেডনেস (একটি ভাগ করা মেমরি মডেলের মধ্যে) এমন একটি সম্পত্তি যা বিমূর্ততার প্রচেষ্টাকে অস্বীকার করে। একটি সরল উদাহরণ হচ্ছে হয় Setটাইপ: যখন Contains(..)এবং Add(...)এবং Update(...)একটি একক থ্রেডেড দৃশ্যকল্প মধ্যে একটি পুরোপুরি বৈধ এপিআই, বহু-থ্রেডেড দৃশ্যকল্প একটি প্রয়োজন AddOrUpdate

একই জিনিসটি ইউআইতে প্রযোজ্য - আপনি যদি তালিকার শীর্ষে থাকা আইটেমগুলির একটি গণনা সহ আইটেমগুলির একটি তালিকা প্রদর্শন করতে চান তবে আপনাকে প্রতিটি পরিবর্তনের জন্য উভয়ই আপডেট করতে হবে।

  1. টুলকিট সেই সমস্যাটি সমাধান করতে পারে না কারণ লক করা নিশ্চিত করে না যে ক্রমের ক্রমটি সঠিক থাকে।
  2. দৃশ্যটি সমস্যার সমাধান করতে পারে তবে কেবলমাত্র যদি আপনি ব্যবসার নিয়মকে তালিকার শীর্ষে থাকা সংখ্যাটি তালিকার আইটেমের সংখ্যার সাথে মেলে এবং কেবলমাত্র ভিউয়ের মাধ্যমে তালিকাকে আপডেট করেন তবেই তা অনুমতি দিন। এমভিসি হওয়ার কথা ঠিক কী নয়।
  3. উপস্থাপক এটিকে সমাধান করতে পারেন তবে থ্রেডিংয়ের ক্ষেত্রে দর্শনটির বিশেষ প্রয়োজন রয়েছে তা সচেতন হওয়া দরকার।
  4. মাল্টি-থ্রেডিং সক্ষম মডেলটির ডেটাবাইন্ডিং অন্য বিকল্প। তবে এটি এমন মডেলগুলিকে জটিল করে তোলে যা ইউআই-উদ্বেগ হওয়া উচিত।

এগুলির কেউই সত্যিই লোভনীয় দেখাচ্ছে না। থ্রেডিং পরিচালনা করার জন্য উপস্থাপককে দায়ী করা বাঞ্ছনীয় এটি ভাল কারণ এটি নয়, তবে এটি কাজ করে এবং বিকল্পগুলি আরও খারাপ।


হতে পারে ভিউ এবং উপস্থাপকের মধ্যে এমন একটি স্তর প্রবর্তন করা যেতে পারে যা অদলবদল হতে পারে।
durron597

2
.NET হয়েছে System.Windows.Threading.Dispatcherউভয় WPF এবং WinForms UI 'তে-টপিক ডিসপ্যাচিং হ্যান্ডেল করতে। উপস্থাপক এবং দর্শনের মধ্যে এই ধরণের স্তরটি অবশ্যই কার্যকর। তবে এটি কেবলমাত্র সরঞ্জামদণ্ডের স্বাধীনতা সরবরাহ করে, স্বাধীনতার থ্রেডিং নয়।
প্যাট্রিক

9

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

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

এসডাব্লুটিটি থিম সুরক্ষার ধারণাটিকে ব্যতিক্রম ছুঁড়ে দিয়ে প্রয়োগ করে যদি এটি লঙ্ঘন করে, সুন্দর নয় তবে কমপক্ষে আপনাকে সে সম্পর্কে সচেতন করা হয়েছে।

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

আপনি সুইং থেকে জাভাএফএক্স-তে পরিবর্তনের কথা উল্লেখ করেছেন, তবে আপনার কোনও ইউআই কাঠামো (কেবল পুরু ক্লায়েন্ট নয়, ওয়েবও) নিয়ে এই সমস্যাটি রয়েছে, সুইং কেবল সমস্যাটিকেই হাইলাইট করে বলে মনে হচ্ছে।

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

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

ঠিক আছে, আপনি কিছুটা সারি রেখে সমস্যার সমাধান করতে পারেন যা ইভেন্টগুলি জারি হওয়ার সময় ভিত্তিক অর্ডার করেছিল, তবে আমাদের ইতিমধ্যে তা কি নেই? তদাতিরিক্ত, আপনি এখনও কোনও গ্যারান্টি দিতে পারেননি যে থ্রেড বি এর থ্রেড এর পরে ইভেন্টগুলি উত্পন্ন করবে

লোকেরা তাদের কোড সম্পর্কে চিন্তাভাবনা করা সম্পর্কে বিরক্ত হওয়ার প্রধান কারণ হ'ল তারা তাদের কোড / ডিজাইন সম্পর্কে চিন্তাভাবনা করে। "কেন এটি সহজ হতে পারে না?" এটি সহজ হতে পারে না, কারণ এটি কোনও সাধারণ সমস্যা নয়।

আমার মনে আছে যখন পিএস 3 প্রকাশিত হয়েছিল এবং সনি সেল প্রসেসরের সাথে কথা বলছিলেন এবং লডিক্সের পৃথক লাইন সম্পাদন, অডিও, ভিডিও, লোড এবং মডেল ডেটা সমাধান করার ক্ষমতা রাখে ability একজন গেম ডেভেলপার জিজ্ঞাসা করেছিলেন, "এগুলি দুর্দান্ত? তবে আপনি কীভাবে স্রোতগুলিকে সমন্বয় করবেন?"

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

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

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

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


2
ওয়েব নিয়ে আপনার এই সমস্যা হবে না। জাভাস্ক্রিপ্ট ইচ্ছাকৃতভাবে কোনও থ্রেডিং সমর্থন নেই - একটি জাভাস্ক্রিপ্ট রানটাইম কার্যকরভাবে মাত্র একটি বড় ইভেন্ট সারি। (হ্যাঁ, আমি জানি যে কঠোরভাবে কথা বলতে বলতে জেএসের ওয়েব ওয়ার্কার্স রয়েছে - এগুলি অসম্পূর্ণ থ্রেড, এবং অন্যান্য ভাষায় অভিনেতাদের মতো আচরণ করে)।
জেমস_পিক

1
@ জেমস_পিক যা আপনার কাছে আসলে ব্রাউজারের অংশটি ইভেন্ট সারিটির সিঙ্ক্রোনাইজার হিসাবে কাজ করে যা মূলত আমরা যে বিষয়ে কথা বলছিলাম, কলারটি
সরঞ্জামদ্বার

হ্যাঁ অবশ্যই. ওয়েবের প্রসঙ্গে মূল পার্থক্যটি হ'ল এই সিঙ্ক্রোনাইজেশনটি কলারের কোড নির্বিশেষে ঘটে থাকে কারণ রানটাইম এমন কোনও প্রক্রিয়া সরবরাহ করে না যা ইভেন্টের সারির বাইরে কোড প্রয়োগের অনুমতি দেয়। সুতরাং কলকারীকে এর জন্য দায়িত্ব নেওয়ার দরকার নেই। আমি বিশ্বাস করি এটি নোডজেএসের বিকাশের পিছনে প্রেরণারও একটি বড় অংশ - যদি রানটাইম পরিবেশটি ইভেন্ট লুপ হয় তবে সমস্ত কোডই ডিফল্টরূপে সচেতন ইভেন্ট লুপ।
জেমস_পিক

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

"ডিসপ্লে-কেবলমাত্র" নিয়ন্ত্রণগুলি স্বয়ংক্রিয়ভাবে থ্রেড-সুরক্ষা সরবরাহ করে কি কোনও বিশেষ সমস্যা হবে? যদি কারও কাছে একটি সম্পাদনাযোগ্য পাঠ্য নিয়ন্ত্রণ থাকে যা এক থ্রেড দ্বারা লিখিত হয় এবং অন্য দ্বারা পড়ে থাকে, নিয়ন্ত্রণের প্রকৃত UI অবস্থায় কমপক্ষে একটি ক্রিয়াকলাপটি সিঙ্ক্রোনাইজ না করে লেখাকে থ্রেডে দৃশ্যমান করার কোনও ভাল উপায় নেই, তবে কেবলমাত্র ডিসপ্লে-নিয়ন্ত্রণের জন্য এই জাতীয় সমস্যাগুলি কি গুরুত্বপূর্ণ? আমার মনে হয় এগুলি সহজেই তাদের উপর সঞ্চালিত ক্রিয়াকলাপগুলির জন্য প্রয়োজনীয় লকিং বা ইন্টারলক সরবরাহ করতে পারে এবং কলারকে কখন এর
সময়টিকে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.