এমভিসিতে বেশ কয়েকটি দর্শন একই কন্ট্রোলার থাকতে পারে বা একটি দৃশ্যে একটি অনন্য নিয়ামক থাকতে হবে?


15

এমভিসির চারপাশে একটি প্রকল্পের জন্য একটি আর্কিটেকচার ডিজাইন করার সময় আমার কিছু প্রশ্ন রয়েছে। (এটি একটি সি ++ / মার্বেল এসডিকে প্রকল্প, আমি কোনও নির্দিষ্ট এমভিসি কাঠামো ব্যবহার করছি না, আমি এটি তৈরি করছি))

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

তবে আমি যখন আমার প্রকল্পে ফিরে আসি তখন দেখতে পেলাম যে একটি নিয়ামক ('লজিকাল ইউনিট' যেমন অ্যাডলেমেন্টকন্ট্রোলারের মতো) এবং সেই নির্দিষ্ট নিয়ামকের জন্য একাধিক মতামত পাওয়া দরকারী।

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

সারসংক্ষেপে এবং এমভিসি প্যাটার্ন সম্পর্কিত (এই কাঠামোর এক্স ফ্রেমওয়ার্কের বিশেষ বোঝা / বাস্তবায়ন নয়) কোনও নিয়ামকের জন্য বেশ কয়েকটি মতামত রাখা কি সঠিক বা প্রতিটি দর্শনেরই এটির নির্দিষ্ট নিয়ামক থাকা উচিত?

এছাড়াও, নিয়ামকের উপর কিছু রাষ্ট্রীয় তথ্য রাখা কি সঠিক বা এটি রাষ্ট্রহীন হওয়া উচিত (অর্থাত্ রাষ্ট্রটি কিছু নন-ডোমেন রাষ্ট্রের মডেলকে রাখা উচিত)?

সকলকে আগাম ধন্যবাদ।

উত্তর:


14

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

একটি বৃহত্তর ক্যানভাস ব্যতীত অন্য কোনও ডায়ালগ অ্যাপ্লিকেশন লিখতে কেমন হবে তা কল্পনা করুন। এমভিসি যে বিশ্ব থেকেই আসে That's

এই সিস্টেমে একটি "ভিউ" ছিল একটি পাঠ্য বাক্স এবং এটি এমন একটি শ্রেণি যা বাক্স, পাঠ্য, নির্বাচিত অঞ্চলগুলি অঙ্কন, পাঠ্যের পরিবর্তনের প্রতিক্রিয়া ইত্যাদির জন্য ...

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

একটি "মডেল" তখন অন্য শ্রেণি যা উপাদানটির বুনিয়াদি ডেটা এবং অবস্থার প্রতিনিধিত্ব করেছিল। একটি পাঠ্য বাক্স মডেলটিতে অবশ্যই পাঠ্য, হরফ, নির্বাচন ইত্যাদি থাকবে ...

আপনি দেখতে পাচ্ছেন, এর মতো পরিস্থিতিতে তিনটি উপাদান একক ধারণার উপস্থাপনে খুব জড়িয়ে পড়ে। এই "ট্রায়াড" এর কথা বলতে এই প্রসঙ্গে অর্থবোধ করে।

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

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

আপনি কি এখনও এমন সম্পর্ককে "ত্রিদেশ" বলতে পারেন? সম্ভবত, তবে আমি মনে করি এটি এমভিসির প্রাক্তন, পুরানো প্রয়োগের খুব বেশি বোঝায়।

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


5

এটা নির্ভর করে. এমভিসির বিভিন্ন রূপ রয়েছে, কিছু যেখানে কেবল 1: 1 সম্পর্কটি বোঝায় ("নম্র ডায়ালগ বক্স" এর মতো), অন্যরা যেখানে এমনটি নয়। সর্বাধিক গুরুত্বপূর্ণ এমভিসি রূপগুলি ব্যাখ্যা করে আমি " বিল্ড ইয়োর নিজের নিজস্ব সিএবি " সিরিজের নিবন্ধগুলি পড়ার পরামর্শ দেব ।


3

এমভিসিতে দৃশ্যের নিয়ন্ত্রণকারী নেই। কন্ট্রোলার হ'ল বস, সুতরাং কোন নিয়ামক সিদ্ধান্ত নেয় যে কোন ভিউটি রেন্ডার করা হবে এবং কোন নিয়ামক এই দৃশ্যের জন্য অনুরোধ করেছেন তা দেখাতে পারে না।

আপনার কাছে / নিয়ামক থেকে একাধিক ভিউ থাকতে পারে। আপনি যদি এমভিসি প্যাটার্নটি ধরে রাখতে চান তবে প্রতিটি দৃশ্যের জন্য একটি মডেল তৈরি করার কথা ভাবুন।


3

নিয়ন্ত্রকের মূল বিষয়টি হ'ল আপনার ডোমেন মডেলটির সাথে ব্যবহারকারীর মিথস্ক্রিয়াকে নিয়ন্ত্রণ করা - অর্থাৎ এটি ব্যবহারকারী যা দেখেন (দেখুন) এবং আপনার অ্যাপ্লিকেশনগুলির অবস্থা (মডেল) এর মধ্যে ইন্ডিয়ারেশনের একটি স্তর।

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

একজন নিয়ামক সর্বদা একই দৃষ্টিভঙ্গি ফিরে আসতে পারে (1: 1) যদি ব্যবহারকারী কেবলমাত্র এক ধরণের অনুরোধ ব্যবহারকারীর দ্বারা নিয়ন্ত্রক করতে পারে এবং এর জন্য সর্বদা একই ধরণের প্রতিক্রিয়া প্রয়োজন। উদাহরণস্বরূপ, HelloWorldControllerসর্বদা HelloWorldView"হ্যালো, ওয়ার্ল্ড!"

অন্যদিকে, একজন নিয়ামককে প্রায়শই বিভিন্ন দৃষ্টিভঙ্গি নিয়ে সিদ্ধান্ত নিতে হয়, মডেল যা বলছে তার উপর নির্ভর করে। TeamRosterControllerএকটি ফিরতি পারে RugbyTeamRosterViewঅথবা একটি FootbalTeamRosterViewদলের অনুরোধ ধরনের উপর নির্ভর করে।

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

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

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