কেন কিউটি মডেল / ভিউ টার্মিনোলজিকে অপব্যবহার করছে?


104

আমি মনে করি মডেল / ভিউ নিয়ন্ত্রণের সাথে কিউটিতে ব্যবহৃত পরিভাষাগুলি ত্রুটিযুক্ত। উপর তাদের ব্যাখ্যা পৃষ্ঠা তারা রাষ্ট্র, যে তারা দেখে ও কন্ট্রোলার মার্জ এবং তারা নিচের ছবি দিচ্ছি দ্বারা এমভি করার MVC সরলীকৃত:

কিউটি এমভিসি ব্যাখ্যা করে ছবি

তবে আমি মনে করি, তারা বস্তুর ভূমিকাটির ভুল নাম দিয়েছে এবং আমি মনে করি যে,

  1. মার্জড কন্ট্রোলারের সাথে তারা কী দেখায় তা আসলে একটি দর্শন।
  2. তারা যাকে মডেল বলে তারা বাস্তবে কেবল নিয়ামক।
  3. আপনি যদি সত্যিই কোনও মডেল রাখতে চান তবে এটি কোথাও হবে যেখানে তাদের "ডেটা" রয়েছে।

আমি স্বাভাবিক এবং বুদ্ধিমান উপায় সম্পর্কে বলছি আপনি নিজের অ্যাপটিতে কিউটি মডেল / ভিউ উপাদানটি ব্যবহার করবেন। এখানে কারণগুলি:

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

তাদের পরিভাষায় কিউটি ভুল আছে, না এটি কেবল আমিই বুঝতে পারি না? (বিটিডাব্লু: এটি একাডেমিক প্রশ্ন না হওয়ার কারণটি হ'ল আমি তাদের নামকরণের পরে আমার প্রকল্পটি কোড করা শুরু করেছি এবং আমি শীঘ্রই জানতে পেরেছি যে কোডটি স্পষ্টভাবে সঠিক নয় is আমি যখন বুঝতে পেরেছিলাম তখনই আমার উচিত ছিল যে মডেল যুক্তিকে তারা মডেল বলার চেষ্টা করবেন না)


1
এমএফসি সিডোক এবং সিভিউ দিয়ে 2 পার্ট মডেল / ভিউ গুইসের মান নির্ধারণ করেছে - কোনও নির্দিষ্ট এমভিসি 'সঠিক' হওয়ার কোনও কারণ নেই
মার্টিন বেকেট

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

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

1
এমভিসি পরিভাষা কোনওভাবেই সর্বসম্মতভাবে সম্মত নয় যাতে আপনার প্রশ্নটি বিতর্কিত হিসাবে বিবেচিত হতে পারে। অনেকে অবশ্য মার্টিন ফোলার ( মার্টিনফোলার . com / eaaDev / index.html ) দ্বারা করা দুর্দান্ত কাজের সাথে একমত হবেন । সাধারণত, নিয়ামক ব্যবহারকারীর ইনপুট পরিচালনা করে এবং এই অর্থে, Qt উইজেটগুলি সুনির্দিষ্টভাবে ভিউ এবং নিয়ামককে একত্রিত করে।
আর্নল্ড স্পেন্স

1
আমি বুঝতে পারি যে এমভিসির অনেক স্বাদ রয়েছে তবে এর অর্থ এই নয় যে কোনও কিছু এমভিসি হতে পারে। কিউটি লাইনটি অতিক্রম করেছে এবং আমি বেশ কয়েকটি কারণ দিয়েছি। মার্টিন ফোলার বিভিন্ন ধরণের এমভিসি ব্যাখ্যা করে তবে কিউটি এমভিসি যা উচ্চারণ করে তার সাথে তার দুটিরও তেমন মিল নেই। সর্বাধিক অনুরূপ মার্টিনফোলার.com / eaaDev / PstreamationModel.html , তবে এটি উপস্থাপনা মডেল = নিয়ন্ত্রক (ব্যবহারকারীর মিথস্ক্রিয়া) অংশ এবং মডেল (ডেটা লজিক) এর মধ্যে পার্থক্য রাখে। সুতরাং যদিও এমভিসির কোনও সুনির্দিষ্ট সংজ্ঞা না থাকলেও কিউটি তাদের কোনওটি অনুসরণ করে না। আপনি যদি আমাকে এই জাতীয় সংজ্ঞায় একটি লিঙ্ক দিতে পারেন তবে দয়া করে এটি করুন।
21

উত্তর:


78

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

  • MFC
  • কিউটি
  • দোল
  • তায়ালা
  • এমভিভিএম সহ ডাব্লুপিএফ

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

যেহেতু অনেক বিভিন্ন ধারনা কি একটি MVC প্যাটার্ন, মত সন্ধান করতে পারেন যা এক সঠিক? আমার মতে, যে ব্যক্তিরা এমভিসি আবিষ্কার করেছিল তাদের যখন "সঠিকভাবে" বাস্তবায়নের কথা রয়েছে তা জানতে চাইলে তাদের দিকে ফেরা উচিত। ইন মূল স্মলটক কাগজ এটা বলেছেন:

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

এর আলোকে আমি আপনার তিনটি প্রধান উদ্বেগের উত্তর এভাবে দেব:

  1. আসলে একটি Qt উপাদান "গ্রাফিক্যাল [...] আউটপুট পরিচালনা করে", এবং "মাউস এবং কীবোর্ডের ইনপুটগুলিকে ব্যাখ্যা করে", সুতরাং এটিকে প্রকৃতপক্ষে উপরের সংজ্ঞাটির সাথে সম্মতভাবে মার্জড ভিউ এবং কন্ট্রোলার বলা যেতে পারে।
  2. আমি সম্মত হই যে আপনি / নিয়ন্ত্রণকারী এবং মডেলকে একীভূত করতে বাধ্য করা হবে (উপরের সংজ্ঞাটি সম্মানের সাথে আবার)।
  3. আমি আবারও একমত। মডেলটির কেবলমাত্র অ্যাপ্লিকেশন ডোমেনের ডেটা পরিচালনা করা উচিত । এটিকেই তারা "ডেটা" বলে call স্পষ্টতই, উদাহরণস্বরূপ সারি এবং কলামগুলির সাথে ডিল করার ক্ষেত্রে আমাদের অ্যাপ্লিকেশন ডোমেনের সাথে সাধারণত কিছু করার থাকে না।

আমাদের কোথায় ছেড়ে যায়? আমার মতে, Qt এর সাথে প্রোগ্রামিং করার সময় "মডেল" এবং "দেখুন" পদটি ব্যবহৃত হয় এবং শব্দগুলি তাদের পদ্ধতিতে ব্যবহার করা হয় তখন Qt এর অর্থ কী তা বোঝা ভাল। যদি আপনি বিরক্ত হন তবে এটি আপনাকে কেবল ধীর করবে এবং কিউটিতে কীভাবে জিনিসগুলি সেট আপ করা হয়েছে তা মার্জিত নকশাকে মঞ্জুরি দেয় - যা তাদের "ভুল" নামকরণের কনভেনশনগুলির ওজনের চেয়ে বেশি।


2
আমি বলব যে প্রতিনিধিটি Qt এর নিয়ামক, যেহেতু প্রতিনিধিরা মডেলটির কাছে ইনপুট গ্রহণ করে এবং প্রেরণ করে, যা সংকেতের মাধ্যমে দৃষ্টিভঙ্গি আপডেট করে।
পেরিগ্রেং-এলকে

82

সংক্ষিপ্ত উত্তর

কিউটির এমভিসি কেবল একটি ডেটা স্ট্রাকচারের জন্য প্রযোজ্য । কোনও এমভিসি অ্যাপ্লিকেশন সম্পর্কে কথা বলার সময় আপনার সম্পর্কে QAbstractItemModelবা ভেবে দেখা উচিত নয় QListView

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


দীর্ঘ উত্তর

কিউটির মডেল / দর্শন পদ্ধতির এবং পরিভাষা:

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

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

এমভিসি পরিভাষায়, মডেলটিতে ডেটা এবং লজিক উভয়ই থাকে । কিউটিতে, আপনার নিজের ব্যবসায়ের কিছু যুক্তি আপনার মডেলটির মধ্যে অন্তর্ভুক্ত করা বা এটি বাইরে রেখে দেওয়া, এটি নিজেই একটি "ভিউ" হয়ে থাকা আপনার পক্ষে you এটি যুক্তি দ্বারা কী বোঝানো হচ্ছে তাও পরিষ্কার নয়: আইটেম নির্বাচন করা, নামকরণ এবং চলাচল করা? => ইতিমধ্যে প্রয়োগ করা হয়েছে। তাদের সাথে গণনা করছেন? => এটিকে মডেল সাবক্লাসের বাইরে বা ভিতরে রাখুন। কোনও ফাইল / থেকে ডেটা সঞ্চয় বা লোড হচ্ছে? => এটি মডেল সাবক্লাসের ভিতরে রাখুন।


আমার ব্যক্তিগত মতামত:

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

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

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


আমি (বড়) অ্যাপ্লিকেশনটির মধ্যে কীভাবে Qt মডেল / ভিউ ব্যবহার করেছি?

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

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

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


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

3
@ সমারলিন: আমি মনে করি না যে এটি সঠিক। একটি কিউলিস্টভিউ এবং কিউটিভিউ ভিউ উভয়ের জন্য কেবল একটি কিউবস্ট্রাক্ট আইটেম ভিউ ইন্টারফেসের প্রয়োজন, যার অর্থ এটির একটি কাস্টম সাবক্লাস, বা কিউস স্ট্যান্ডার্ড আইটেমমোডেলের মতো একটি কংক্রিট শ্রেণীর উভয়ের জন্য সেই প্রয়োজনীয়তা পুরো ফিল করা উচিত। আপনি একটি গাছ চালনা করতে পারেন এবং একটি মডেলের তালিকা তৈরি করতে পারেন।
jdi

1
@ জেডি: এমন কিছু ঘটনা রয়েছে যেখানে আপনার ডেটা, তালিকা এবং একটি গাছ উভয়ই রয়েছে ... যেমন আপনি আপনার ফাইল সিস্টেমটিকে গাছ হিসাবে বা সমস্ত ফাইলকে একটি তালিকা হিসাবে প্রদর্শন করতে চান। Qts মডেলগুলি সঠিকভাবে এটির অনুমতি দেয় না। QAbstractItemModel টি ট্রি ভিউ সমর্থনকারী প্রয়োগ, কেবলমাত্র আপনার রুট ডিরেক্টরিতে সমস্ত ফাইল / ডিরেক্টরিকে তালিকা হিসাবে প্রদর্শন করার অনুমতি দেয় তবে আপনি সমস্ত ফাইলকে তালিকা হিসাবে প্রদর্শন করতে পারবেন না। এবং এটি বলতে চাইবেন না যে তালিকার গাছ হিসাবে ডেটা প্রদর্শন করা দরকারী। উদাহরণস্বরূপ, উদাহরণস্বরূপ, আপনি খুব সহজেই তাদের সর্বাধিক ফাইলসাইজ সহ ফাইলটি সৃস্ট করতে পারেন যদি আপনি আপনার ফাইলগুলি তালিকা হিসাবে প্রদর্শন করেন তবে গাছের দর্শনগুলি এটির অনুমতি দেয় না।
স্মারলিন

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

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

12

পরিভাষাটি সঠিক বা ভুল নয়, এটি দরকারী বা অকেজো।

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


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

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

আপনার কি কোনও অন্তর্দৃষ্টি রয়েছে যে কীভাবে এমভিসি পরিভাষাটি কিউটিতে সম্মত হয়েছে? এটি কোড লেখার সময়, বা কেবলমাত্র ডকুমেন্টেশন প্রক্রিয়া চলাকালীন ব্যবহৃত হয়েছিল?
জন্মগ্রহণ করুন

ট্রোলটেক-এ আমার সময়কালে আমরা Qt ডকুমেন্টেশনে "এমভিসি" শব্দটি ব্যবহার করি নি। সাধারণভাবে আমি মনে করি সেখানে যা আছে তা নথিভুক্ত করা সবচেয়ে ভাল, সেখানে কী নেই তা সম্পর্কে লিখবেন না। যাইহোক, উদ্বিগ্নতার সাথে আপনি খুঁজে পেতে পারেন যে সেই পাঠ্যটি কে যুক্ত করেছেন এবং সেই ব্যক্তিকে সরাসরি যুক্ত করেছেন।
ARNT

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

3

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


2

আমি বিশ্বাস করি যে তাদের পরিভাষাটি সঠিক ... যদিও বাস্তব অ্যাপ্লিকেশনগুলিতে আমি দেখতে পেয়েছি যে আপনার বিমূর্ততার স্তরের উপর নির্ভর করে মডেল, দর্শন এবং নিয়ামকের মধ্যে লাইনগুলি ঝাপসা করা খুব সহজ হতে পারে: এক স্তরের দৃষ্টিভঙ্গি উচ্চ স্তরের মডেল হতে পারে।

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


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

0

আমি মনে করি ... তারা যাকে মডেল বলে তারা আসলে কন্ট্রোলার।

না, তাদের "মডেল" অবশ্যই নিয়ামক নয়।

নিয়ামক ব্যবহারকারীর দৃশ্যমান নিয়ন্ত্রণগুলির অংশ যা মডেলটি সংশোধন করে (এবং সুতরাং অপ্রত্যক্ষভাবে ভিউটি সংশোধন করে)। উদাহরণস্বরূপ, একটি "মুছুন" বোতামটি নিয়ামকের অংশ।

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

এমভিসি আবিষ্কার হওয়ার পরে, নিয়ামক এবং দৃশ্যের মধ্যে এর পার্থক্য ক্রমশ উত্তেজনাপূর্ণ হয়ে উঠেছে। একটি পাঠ্য বাক্স সম্পর্কে চিন্তা করুন: এটি উভয়ই আপনাকে কিছু পাঠ্য দেখায় এবং আপনাকে এটি সম্পাদনা করতে দেয়, তবে এটি কী দেখা বা নিয়ামক? উত্তরটি হ'ল এটি উভয়েরই একটি অংশ। ১৯ you০ এর দশকে যখন আপনি একটি টেলি টাইপে কাজ করছিলেন তখন পার্থক্যটি আরও স্পষ্ট হয়েছিল - চিন্তা করুন thinked - তবে এর অর্থ এই নয় যে তখনকার ব্যবহারকারীর পক্ষে জিনিসগুলি আরও ভাল ছিল!

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.