এমভিসি (মডেল, ভিউ, কন্ট্রোলার) রক্ষণাবেক্ষণযোগ্যতা উন্নত করতে একটি অ্যাপ্লিকেশনটিতে কোড সংগঠিত করার একটি প্যাটার্ন।
কোনও স্টুডিওতে কোনও ফটোগ্রাফারকে তার ক্যামেরা সহ কল্পনা করুন। একজন গ্রাহক তাকে একটি বাক্সের ছবি তুলতে বললেন।
নন-এমভিসি আর্কিটেকচারগুলি একত্রে দৃly়ভাবে একীভূত হওয়ার প্রবণতা রয়েছে। যদি বাক্স, কন্ট্রোলার এবং ক্যামেরা তখন এক এবং একই জিনিস ছিল, আমাদের আলাদা করে টানতে হবে এবং প্রতিবার নতুন দৃশ্য পেতে চাইলে বাক্স এবং ক্যামেরা উভয়ই আবার তৈরি করতে হবে। এছাড়াও, ফটো তোলা সর্বদা একটি সেলফি তোলার চেষ্টা করার মতোই হবে - এবং এটি সবসময় খুব সহজ নয়।
বাওয়াহা লিখেছেন:
লেখক এমভিসি ডিজাইনের উদাহরণ হিসাবে ডাব্লুএক্সপিথনে mvctree.py উল্লেখ করেছেন। তবে আমি এখনও খুব সবুজ তাই আমি সেই নির্দিষ্ট উদাহরণটিকে খুব জটিল মনে করি এবং লেখক যে সুপারিশ করছেন তা আমি বুঝতে পারছি না।
এমভিসি সমস্ত উদ্বেগের বিচ্ছেদ সম্পর্কে is
মডেল প্রোগ্রামটির ডেটা (উভয় ব্যক্তিগত এবং ক্লায়েন্ট ডেটা) পরিচালনার জন্য দায়বদ্ধ। ভিউ / কন্ট্রোলার বাইরের বিশ্বকে প্রোগ্রামটির ক্লায়েন্টের ডেটার সাথে যোগাযোগের উপায় সরবরাহ করার জন্য দায়বদ্ধ।
প্রোগ্রামটির অন্যান্য অংশগুলি এটির সাথে ইন্টারঅ্যাক্ট করতে সক্ষম করার জন্য মডেল একটি অভ্যন্তরীণ ইন্টারফেস (এপিআই) সরবরাহ করে। ভিউ / কন্ট্রোলার একটি বাহ্যিক ইন্টারফেস (জিইউআই / সিএলআই / ওয়েব ফর্ম / উচ্চ স্তরের আইপিসি / ইত্যাদি) সরবরাহ করে যাতে প্রোগ্রামটির সাথে যোগাযোগের বাইরে সমস্ত কিছু সক্ষম করে তোলে।
মডেলটি প্রোগ্রামের ডেটার অখণ্ডতা বজায় রাখার জন্য দায়ী, কারণ যদি এটি দূষিত হয় তবে এটি সবার জন্য খেলা শেষ। ভিউ / কন্ট্রোলার ইউআইয়ের অখণ্ডতা বজায় রাখার জন্য দায়বদ্ধ, সমস্ত পাঠ্য দর্শনগুলি আপ-টু-ডেট মান প্রদর্শন করছে, মেনু আইটেমগুলি অক্ষম করবে যা বর্তমান ফোকাসে প্রযোজ্য নয় ইত্যাদি is
মডেলটিতে কোনও ভিউ / কন্ট্রোলার কোড নেই; কোনও জিইউআই উইজেট ক্লাস নেই, ডায়লগ বাক্স রাখার বা ব্যবহারকারীর ইনপুট পাওয়ার জন্য কোনও কোড নেই। ভিউ / কন্ট্রোলারে কোনও মডেল কোড নেই; ইউআরএলগুলিকে বৈধতা দেওয়ার জন্য বা এসকিউএল কোয়েরিগুলি সম্পাদন করার জন্য কোনও কোড নেই এবং কোনও মূল অবস্থাও নয়: উইজেটগুলির দ্বারা রাখা কোনও ডেটা কেবল প্রদর্শনের উদ্দেশ্যে, এবং কেবলমাত্র মডেলটিতে সঞ্চিত সত্য ডেটার প্রতিচ্ছবি।
এখন, এখানে সত্যিকারের এমভিসি ডিজাইনের পরীক্ষা করা হচ্ছে: প্রোগ্রামটি সংক্ষিপ্তভাবে কোনও ভিউ / কন্ট্রোলার সংযুক্ত না করে পুরোপুরি কার্যকরভাবে হওয়া উচিত। ঠিক আছে, বাইরের বিশ্বটিকে সেই ফর্মটিতে এটির সাথে আলাপচারিতা করতে সমস্যা হবে, তবে যতক্ষণ না কেউ যথাযথ মডেল API এঙ্কটিশনগুলি জানেন, প্রোগ্রামটি স্বাভাবিক হিসাবে ডেটা ধরে রাখে এবং ম্যানিপুলেট করে।
কেন এটা সম্ভব? ভাল, সহজ উত্তরটি হ'ল এটি সমস্ত মডেল এবং দেখুন / নিয়ন্ত্রণকারী স্তরগুলির মধ্যে সংযুক্ত লোকে সংযুক্ত হওয়ার জন্য ধন্যবাদ। তবে এটি সম্পূর্ণ গল্প নয়। কি পুরো MVC প্যাটার্ন চাবিকাঠি হয় দিক সমস্ত নির্দেশাবলী প্রবাহিত যা ঐ সংযোগ যায় থেকে দেখুন / কন্ট্রোলার থেকে মডেল। কখনও কখনও মডেলটি ভিউ / নিয়ন্ত্রণকারীকে কী করতে হবে তা জানায় tells
কেন? কারণ এমভিসি-তে, যখন ভিউ / কন্ট্রোলারকে মডেল সম্পর্কে কিছুটা জানার অনুমতি দেওয়া হয় (বিশেষত, মডেলটির এপিআই) তবে ভিউ / কন্ট্রোলার সম্পর্কে মডেলকে কিছু জানার অনুমতি নেই।
কেন? কারণ এমভিসি উদ্বেগের স্পষ্ট বিচ্ছিন্নতা তৈরি করার বিষয়ে।
কেন? প্রোগ্রামের জটিলতা নিয়ন্ত্রণের বাইরে ছিটানো এবং এর অধীনে আপনাকে, বিকাশকারীকে কবর দেওয়া রোধ করতে সহায়তা করতে। প্রোগ্রামটি যত বড়, সেই প্রোগ্রামের উপাদানগুলির সংখ্যা তত বেশি। এবং এই উপাদানগুলির মধ্যে আরও সংযোগ বিদ্যমান, বিকাশকারীদের পৃথক উপাদান বজায় রাখা / প্রসারিত / প্রতিস্থাপন করা এমনকি পুরো সিস্টেমটি কীভাবে কাজ করে তা কেবল অনুসরণ করা তত কঠিন। নিজেকে এটিকে জিজ্ঞাসা করুন: প্রোগ্রামটির কাঠামোর ডায়াগ্রামের দিকে তাকানোর সময়, আপনি বরং গাছ বা একটি বিড়ালের প্যাঁচ দেখতে পাবেন? এমভিসি প্যাটার্নটি বিজ্ঞপ্তি সংযোগগুলি অস্বীকার করে পরবর্তীটিকে এড়িয়ে চলে: বি এ এর সাথে সংযোগ করতে পারে তবে এ বি এর সাথে সংযোগ করতে পারে না এই ক্ষেত্রে, এ হ'ল মডেল এবং বি হ'ল / নিয়ন্ত্রণকারী।
বিটিডাব্লু, আপনি যদি তীক্ষ্ণ হন তবে আপনি কেবলমাত্র বর্ণিত 'ওয়ান-ওয়ে' বিধিনিষেধের সাথে একটি সমস্যা লক্ষ্য করবেন: মডেল এমনকি ব্যবহারকারীদের যখন ডেটা পরিবর্তন করতে পারে তার মডেলটি তার ম্যানেজারকে কীভাবে জানাতে পারে? জেনে রাখুন যে ভিউ / কন্ট্রোলার, তাতে কোনও বার্তা পাঠাতে আপত্তি নেই? তবে চিন্তা করবেন না: এটির একটি সমাধান রয়েছে এবং এটি প্রথমে কিছুটা চতুর্দিক থেকে মনে হলেও এটি ঝরঝরে। আমরা এক মুহুর্তে ফিরে আসব।
তারপরে ব্যবহারিক পদগুলিতে, কোনও ভিউ / কন্ট্রোলার অবজেক্ট মডেলটির এপিআই এর মাধ্যমে, ১. মডেলকে জিনিসগুলি করতে বলে (আদেশগুলি কার্যকর করে), এবং ২. মডেলকে জিনিস (রিটার্ন ডেটা) দেওয়ার জন্য বলে। ভিউ / কন্ট্রোলার স্তরটি
মডেল স্তরের নির্দেশকে ধাক্কা দেয় এবং মডেল স্তর থেকে তথ্য টান দেয় ।
এবং সেখানেই আপনার প্রথম মাইকুললিস্টকন্ট্রোল উদাহরণটি ভুল হয়ে গেছে, কারণ class শ্রেণীর API টির জন্য সেই তথ্যটি ধাক্কা
দেওয়া দরকার , সুতরাং আপনি স্তরগুলির মধ্যে দ্বিমুখী সংযোগ স্থাপন করে ফিরে এসেছেন, এমভিসি নিয়ম লঙ্ঘন করে এবং আপনাকে ঠিক আবার ডাম্পের মধ্যে ফেলে দিচ্ছেন বিড়ালের ক্র্যাডল আর্কিটেকচার যা আপনি [সম্ভবত] প্রথম স্থানে এড়াতে চাইছিলেন।
পরিবর্তে, মাইকুললিস্টকন্ট্রোল শ্রেণীর প্রবাহের সাথে চলতে হবে, যখন এটির প্রয়োজন হবে তখন নীচের স্তর থেকে প্রয়োজনীয় ডেটা টানতে হবে। একটি তালিকা উইজেটের ক্ষেত্রে, এর অর্থ সাধারণত সেখানে কতগুলি মান রয়েছে তা জিজ্ঞাসা করা এবং তারপরে প্রতিটি আইটেমের জন্য জিজ্ঞাসা করা, কারণ এটি করা সহজ এবং স্বাচ্ছন্দ্যের উপায় এবং তাই সেখানে মিলিত হওয়াটি ন্যূনতম পর্যন্ত রাখে। এবং যদি উইজেটটি চায়, বলুন, ভাল বর্ণানুক্রমিক ক্রমে এই মানগুলি ব্যবহারকারীর সামনে উপস্থাপন করতে পারেন তবে এটি তার পার্সোভেটিভ; এবং অবশ্যই এর দায়বদ্ধতা।
এখন, একটি শেষ কনড্রাম, যেমন আমি আগে ইঙ্গিত দিয়েছিলাম: আপনি কীভাবে ইউভির ডিসপ্লেটিকে এমভিসি ভিত্তিক সিস্টেমে মডেলের রাজ্যের সাথে সুসংগত রাখবেন?
এখানে সমস্যাটি রয়েছে: অনেকগুলি ভিউ অবজেক্টগুলি রাষ্ট্রীয়, উদাহরণস্বরূপ একটি চেকবক্সটি টিক চিহ্নযুক্ত বা আনস্টিক করা যেতে পারে, একটি পাঠ্য ক্ষেত্রে কিছু সম্পাদনাযোগ্য পাঠ্য থাকতে পারে। যাইহোক, এমভিসি নির্দেশ দেয় যে সমস্ত ব্যবহারকারীর ডেটা মডেল স্তরে সংরক্ষণ করা উচিত, সুতরাং প্রদর্শনের উদ্দেশ্যে অন্যান্য স্তরগুলির দ্বারা রাখা কোনও ডেটা (চেকবক্সের রাজ্য, পাঠ্য ক্ষেত্রের বর্তমান পাঠ্য) অবশ্যই সেই প্রাথমিক মডেলের ডেটার সহায়ক কপি হতে হবে। তবে যদি মডেলের রাজ্য পরিবর্তন হয় তবে সেই রাজ্যের ভিউ'র অনুলিপিটি আর সঠিক হবে না এবং তা রিফ্রেশ করা দরকার।
কিন্তু কিভাবে? এমভিসি প্যাটার্নটি মডেলটিকে ভিউ স্তরটিতে সেই তথ্যের একটি নতুন অনুলিপি ঠেলে দেয়। হেক, এটি এমনকি মডেলটিকে দৃশ্যটির বার্তা প্রেরণের অনুমতি দেয় না এটি বলার জন্য যে এর রাজ্য পরিবর্তন হয়েছে।
ভাল প্রায়. ঠিক আছে, মডেল স্তরটিকে অন্য স্তরগুলির সাথে সরাসরি কথা বলার অনুমতি নেই, যেহেতু এটি করার জন্য সেই স্তরগুলির সম্পর্কে কিছু জানা থাকতে হবে এবং এমভিসি নিয়মগুলি এটি প্রতিরোধ করে। তবে, কোন গাছ যদি কোনও বনের মধ্যে পড়ে এবং এটি শুনতে কেউ চারপাশে না থাকে, এটি কি শব্দ করে?
উত্তরটি, আপনি দেখতে পাচ্ছেন, একটি বিজ্ঞপ্তি সিস্টেম সেট আপ করা, মডেল স্তরটিকে এমন একটি জায়গা প্রদান করা যা এটি বিশেষভাবে কারও কাছেই ঘোষণা করা যায় না যে এটি সবেমাত্র আকর্ষণীয় কিছু করেছে। তারপরে অন্যান্য স্তরগুলি শ্রোতাদের সেই বিজ্ঞপ্তি সিস্টেমের সাথে সেই ঘোষণাগুলি শোনার জন্য পোস্ট করতে পারে যেগুলিতে তারা আগ্রহী তারা। এটি কেবল একটি ঘোষণা পোস্ট করে এবং তারপরে এটি ভুলে যায়। এবং যদি কেউ এই ঘোষণাটি শুনে এবং তারপরে কিছু করার মতো মনে করে - যেমন কিছু নতুন ডেটার জন্য মডেলকে জিজ্ঞাসা করা যাতে এটি তার অন স্ক্রিন প্রদর্শন আপডেট করতে পারে - তবে দুর্দান্ত। মডেলটি কেবলমাত্র তার এপিআই সংজ্ঞায়নের অংশ হিসাবে কোন বিজ্ঞপ্তিগুলি প্রেরণ করে তা তালিকাভুক্ত করে; এবং এই জ্ঞান সহ অন্য কেউ যা করেন তা তাদের উপর নির্ভর করে।
এমভিসি সংরক্ষিত, এবং সবাই খুশি। আপনার অ্যাপ্লিকেশন ফ্রেমওয়ার্কটি একটি বিল্ট-ইন নোটিফিকেশন সিস্টেমটি সরবরাহ করতে পারে, বা আপনি না লিখলে নিজের লিখতে পারেন ('পর্যবেক্ষক বিন্যাস দেখুন')।
...
যাইহোক, আশা করি এটি সাহায্য করে। একবার আপনি এমভিসির পিছনে অনুপ্রেরণাগুলি বুঝতে পারলে, জিনিসগুলি কেন এভাবে শুরু হয় তার কারণগুলি বুঝতে শুরু করে, এমনকি যখন - প্রথম নজরেও - তারা প্রয়োজনের চেয়ে আরও জটিল বলে মনে হয়।
চিয়ার্স,
হয়েছে