"এমভিসি" এর "কন্ট্রোলার" এর মধ্যে কী যায়?


186

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

উদাহরণস্বরূপ বলি যে আমার কাছে মোটামুটি সহজ অ্যাপ্লিকেশন রয়েছে (আমি বিশেষত জাভা ভাবছি তবে আমি মনে করি একই নীতিগুলি অন্য কোথাও প্রয়োগ হয়)। আমি আমার কোডটি 3 টি প্যাকেজ নামে পরিচিত app.model, app.viewএবং app.controller

app.modelপ্যাকেজের মধ্যে আমার কয়েকটি শ্রেণি রয়েছে যা অ্যাপ্লিকেশনটির আসল আচরণকে প্রতিবিম্বিত করে। এগুলি extends Observableব্যবহার করুন setChanged()এবং notifyObservers()যখন উপযুক্ত হবে আপডেট করার জন্য ভিউগুলি ট্রিগার করুন।

app.viewপ্যাকেজের মাধ্যমে একটি শ্রেণী (বা প্রদর্শন বিভিন্ন ধরনের জন্য বিভিন্ন শ্রেণীর) ব্যবহার করে রয়েছে javax.swingডিসপ্লে হ্যান্ডেল করতে উপাদান। এর মধ্যে কয়েকটি উপাদানকে আবার মডেলটিতে ফিড করা দরকার। যদি আমি সঠিকভাবে বুঝতে পারি তবে ভিউটির প্রতিক্রিয়াটির সাথে কিছু করা উচিত নয় - যা কন্ট্রোলার দ্বারা মোকাবেলা করা উচিত।

তাহলে আমি আসলে কন্ট্রোলারে কী রাখি? আমি public void actionPerformed(ActionEvent e)কি নিয়ামকের কোনও পদ্ধতিতে কেবল কল দিয়ে ভিউতে রাখি? যদি তা হয় তবে কোনও বৈধকরণ ইত্যাদি কি নিয়ামক মধ্যে করা উচিত? যদি তা হয়, তবে আমি কীভাবে ত্রুটি বার্তাগুলির প্রতিক্রিয়া জানব সেগুলিতে - কী আবার মডেলটির মধ্য দিয়ে যাওয়া উচিত, বা কন্ট্রোলারকে কেবল এটি সরাসরি দেখার জন্য প্রেরণ করা উচিত?

যদি ভিউতে বৈধতা হয় তবে আমি কন্ট্রোলারে কী রাখি?

দীর্ঘ প্রশ্নের জন্য দুঃখিত, আমি কেবল প্রক্রিয়া সম্পর্কে আমার বোঝার নথিটি চেয়েছিলাম এবং আশা করি কেউ আমার জন্য এই বিষয়টি পরিষ্কার করে দিতে পারে!

উত্তর:


519

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

কথোপকথনের আকারে:

দেখুন : "আরে, নিয়ামক, ব্যবহারকারী আমাকে কেবল বলেছিলেন যে তিনি আইটেম 4 মুছে ফেলতে চান।"
কন্ট্রোলার : "হুম, তার শংসাপত্রগুলি যাচাই করে, তাকে এটি করার অনুমতি দেওয়া হয়েছে ... আরে, মডেল, আমি চাই আপনি আইটেম 4 পেয়ে যাবেন এবং এটি মুছতে আপনি যা করেন তা করুন।"
মডেল : "আইটেম 4 ... এটি পেয়েছে It's এটি মুছে ফেলা হয়েছে you আপনার কাছে ফিরে আসুন, কন্ট্রোলার।"
নিয়ন্ত্রক : "এখানে, আমি ডেটার নতুন সেট সংগ্রহ করব you আপনার কাছে ফিরে আসুন, দেখুন view"
দেখুন : "শীতল, আমি এখন ব্যবহারকারীকে নতুন সেটটি দেখাব show"

বিভাগটির শেষে, আপনার একটি বিকল্প রয়েছে: হয় ভিউ একটি পৃথক অনুরোধ করতে পারে, "আমাকে সর্বাধিক সাম্প্রতিক ডেটা সেট করুন", এবং এইভাবে আরও খাঁটি হতে পারে, বা নিয়ামকটি "মুছুন" সহ নতুন ডেটা সেটটিকে সুস্পষ্টভাবে ফিরিয়ে দেয় " অপারেশন.


90
এই কথোপকথনটি এমভিসি-র সেরা ব্যাখ্যা যা আমি এসেছি, ধন্যবাদ!
পল ওয়াকার

13
সব ঠিক আছে, তবে সরাসরি মডেল থেকে ভিউ রিডিংয়ে কোনও ভুল নেই । "নিয়ন্ত্রণকারীরা ডেটা পুলিশ নয়" are একটি মতবাদ রয়েছে যা নিয়ামকদের পাতলা রাখতে বলে। আপনার সহায়তায় গ্রাস করার জন্য প্রস্তুত ডেটা সংগ্রহের জন্য ভিউ হেল্পাররা একটি উপযুক্ত জায়গা। কিছু ডেটা অ্যাক্সেস যুক্তি পুনরায় ব্যবহার করতে সম্পূর্ণ নিয়ামক স্ট্যাক প্রেরণ করা উচিত নয়। আরও বিশদ: rmauger.co.uk/2009/03/…
ব্যতিক্রম ই

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

68

সমস্যাটি MVCহ'ল লোকেরা মনে করে যে দেখুন, নিয়ন্ত্রণকারী এবং মডেলটিকে একে অপরের থেকে যথাসম্ভব স্বতন্ত্র হতে হবে। তারা না - একটি দৃশ্য এবং নিয়ামক প্রায়ই বিজড়িত হয় - হিসাবে মনে M(VC)

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

মডেল হিসাবে সিল করা বাক্সে সনাক্তকরণের ক্ষেত্রের একটি রেডিও-নিয়ন্ত্রিত রোবটটিকে ভাবুন।

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

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

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

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

আমি কি আপনার প্রশ্নের উত্তর দিয়েছি? :-)

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

... কোন বৈধতা ইত্যাদি নিয়ামক মধ্যে করা উচিত? যদি তা হয়, তবে আমি কীভাবে ত্রুটি বার্তাগুলির প্রতিক্রিয়া জানব সেগুলিতে - কী আবার মডেলটির মধ্য দিয়ে যাওয়া উচিত, বা কন্ট্রোলারকে কেবল এটি সরাসরি দেখার জন্য প্রেরণ করা উচিত?

যদি ভিউতে বৈধতা হয় তবে আমি কন্ট্রোলারে কী রাখি?

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

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

টাচস্ক্রিনযুক্ত লোকটি যদি রোবটটি মাঠের বাইরে পাঠানোর চেষ্টা করে, তবে তিনি একটি দুর্দান্ত ব্যবহারকারীর বন্ধুত্বপূর্ণ বার্তা পেয়েছিলেন যাতে তিনি সনাক্তকরণের ক্ষেত্রটি পাঠিয়ে রোবটটিকে হত্যা করবেন না, তবে আবার কারও কাছে এটি জানার দরকার নেই।

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


23

এখানে এমভিসির মূল বিষয়গুলি সম্পর্কে একটি ভাল নিবন্ধ দেওয়া আছে

এতে বলা হয়েছে ...

নিয়ামক - নিয়ামক মডেল দ্বারা সম্পাদিত করা কর্মগুলিতে দৃশ্যের সাথে ইন্টারঅ্যাকশনগুলিকে অনুবাদ করে।

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

ফাউলারে আরও একটি ভাল নিবন্ধ রয়েছে


আপনি যে নিবন্ধটি উল্লেখ করেছেন তাতে এমভিপি হ'ল আরেকটি বিকল্প, মার্টিনফাউলার
জন

লিঙ্কগুলির জন্য ধন্যবাদ, তারা অবশ্যই আকর্ষণীয় পড়ার জন্য তৈরি করে।
পল ওয়াকার

18

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


1
হুবহু, আমি এখনও অবধি যা ভাবতাম তবে কাউকে বলার সাহস পাইনি .... বা যথাযথ শব্দ দিয়ে আসতে পারে না।
user1451111

1
মডেল-দেখুন-বিভ্রান্তি
বৃষ্টি হচ্ছে

10

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

ব্যক্তিগতভাবে, পূর্ণ-বিকাশিত এমভিসিটি কারখানার নকশার প্যাটার্নের মতো মনে হয় যা এটি সহজেই বিভ্রান্তিকর এবং অতিরিক্ত জটিল ডিজাইনের দিকে নিয়ে যায়। কোনও আর্কিটেকচার নভোচারী হবেন না ।


9

আপনার প্রশ্নের ভিত্তিতে, আমি ধারণাটি পেয়েছি যে আপনি মডেলের ভূমিকায় কিছুটা দুর্বল। মডেলটি অ্যাপ্লিকেশনটির সাথে সম্পর্কিত ডেটাগুলিতে স্থির হয়; যদি অ্যাপটির কোনও ডাটাবেস থাকে তবে মডেলের কাজটি এটির সাথে কথা বলা হবে। এটি সেই ডেটা সম্পর্কিত কোনও সাধারণ যুক্তিও পরিচালনা করবে; আপনার যদি এমন কোনও নিয়ম থাকে যা বলে যে TABLE.foo == "হুররে!" এবং টেবল.বার == "হুজাহ!" তারপরে TABLE.field = "W00t!" সেট করুন, তারপরে আপনি চান মডেলটি এটির যত্ন নেবে।

নিয়ামক হ'ল অ্যাপ্লিকেশনটির বেশিরভাগ আচরণের নিয়ন্ত্রণ করা উচিত। সুতরাং আপনার প্রশ্নের উত্তর দিতে:

আমি কি নিয়ামকের কোনও পদ্ধতির কেবলমাত্র কল দিয়ে ভিউতে সর্বজনীন শূন্য অ্যাকশনপ্রাপ্ত (অ্যাকশনসেন্ট ই) রেখেছি?

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

যদি তা হয় তবে কোনও বৈধকরণ ইত্যাদি কি নিয়ামক মধ্যে করা উচিত?

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

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

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

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

যদি ভিউতে বৈধতা হয় তবে আমি কন্ট্রোলারে কী রাখি?

উপরে দেখুন; আসল বৈধতা নিয়ন্ত্রকের মধ্যে থাকা উচিত। এবং আশা করি এখনই আপনার নিয়ামকটিতে কী রাখা উচিত সে সম্পর্কে আপনার কিছু ধারণা রয়েছে। :-)

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


7

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

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

পরিষেবামুখী: কাজটি এখানেই করা হয়েছে।


3

নিয়ামকটি মূলত ভিউ এবং মডেলের মধ্যে সমন্বয় সাধনের জন্য।

দুর্ভাগ্যক্রমে, কখনও কখনও এটি দৃশ্যের সাথে একত্রে মিশে যায় - ছোট অ্যাপগুলিতে এটি খুব খারাপ না হলেও।

আমি আপনাকে রাখার পরামর্শ দিচ্ছি:

public void actionPerformed(ActionEvent e)

নিয়ামক মধ্যে। তারপরে আপনার দৃষ্টিতে আপনার অ্যাকশন শ্রোতার উচিত নিয়ামকের কাছে প্রতিনিধি।

বৈধতা অংশ হিসাবে, আপনি এটি ভিউ বা নিয়ামকের মধ্যে রাখতে পারেন, আমি ব্যক্তিগতভাবে মনে করি এটি নিয়ামকের অন্তর্ভুক্ত।

আমি অবশ্যই প্যাসিভ ভিউ এবং তদারকি উপস্থাপক (যা মূলত মডেল ভিউ উপস্থাপককে বিভক্ত করা হয়েছে - কমপক্ষে ফওলারের দ্বারা) এ একবার দেখার পরামর্শ দিচ্ছি। দেখা:

http://www.martinfowler.com/eaaDev/PassiveScreen.html

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html


3

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

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


1

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


1

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

যাইহোক, একটি যথাযথ এমভিসি বাস্তবায়নের জন্য কেবল নিম্নলিখিত ইন্টারঅ্যাকশন থাকবে: মডেল -> দেখুন দেখুন -> নিয়ামক নিয়ন্ত্রণকারী -> দেখুন

কেবলমাত্র অন্য জায়গার ইন্টারঅ্যাকশন থাকতে পারে যেখানে আপনি কোনও ভিউ আপডেট করার জন্য কোনও পর্যবেক্ষক ব্যবহার করেন, তারপরে ভিউটির জন্য প্রয়োজনীয় তথ্যটির জন্য নিয়ামককে জিজ্ঞাসা করা দরকার।


0

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


0

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

(1) (প্রতিক্রিয়া, প্রতিক্রিয়া - ওয়েব অ্যাপ্লিকেশন ব্যবহারকারীদের প্রতিক্রিয়াতে "কী করে") Blog_Controller

-> মেন ()

-> handleSubmit_AddNewCustomer ()

-> verifyUser_HasProperAuth ()

(2) ("ব্যবসায়" যুক্তি, কী এবং কীভাবে ওয়েব অ্যাপ "চিন্তা করে") ব্লগ_লজিক

-> sanityCheck_AddNewCustomer ()

-> handleUsernameChange ()

-> sendEmail_NotifyRequestedUpdate ()

(3) (ভিউ, পোর্টাল, ওয়েব অ্যাপ্লিকেশনটি কীভাবে "প্রদর্শিত হবে") ব্লগ_ভিউ

-> genWelcome ()

-> genForm_AddNewBlogEntry ()

-> genPage_DataEntryForm ()

(৪) (কেবলমাত্র প্রতিটি ব্লগ * বর্গের _ কনস্ট্রাক্ট ( ) -তে অর্জিত ডেটা অবজেক্ট, সমস্ত ওয়েবঅ্যাপ / ইনমেমরি ডেটা এক সাথে রাখার জন্য ব্যবহৃত) ব্লগ_মেটা

(5) (বেসিক ডেটা স্তর, ডিবিগুলিকে পড়তে / লেখায়) ব্লগ_মোডেল

-> saveDataToMemcache ()

-> saveDataToMongo ()

-> saveDataToSql ()

-> loadData ()

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

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