একটি দৃশ্য এবং একটি মডেল যোগাযোগ করা উচিত বা না?


33

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

এই দুটি বিপরীত দৃষ্টিভঙ্গি আপনি কীভাবে ব্যাখ্যা করবেন?

উত্তর:


26

এটি এমভিসি / এমভিভিএম-এ একটি বিতর্কিত বিষয়। কেউ কেউ বলেছেন যে মডেলগুলিকে সরাসরি অ্যাক্সেস করা ভিউয়ের পক্ষে ঠিক, আমি ব্যক্তিগতভাবে উভয় পদ্ধতির ভক্ত নই।

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

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


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

+1 দুর্দান্ত উত্তর! আপনার মডেলের জটিলতার উপর নির্ভর করে এটি দুর্দান্ত পদ্ধতি, তবে বর্তমানে বেশিরভাগ মডেল অ্যানিমিক ধরণের। মডেলটির উপাদানগুলি, বিনা আচরণে ডেটা অবজেক্টগুলির চেয়ে সামান্য বেশি হওয়ায় আমি আপনার দৃষ্টিভঙ্গিকে সরাসরি আপনার মডেলটিতে অ্যাক্সেস করার অনুমতি দেওয়ার ক্ষেত্রে এ জাতীয় বিমূর্ততা এবং সামান্য বিপদের দরকার নেই।
maple_shaft

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

1
আমি বিভ্রান্ত, যদি আপনার কাছে এমন একাধিক মতামত থাকে যা একেবারেই আলাদা হয় তবে কীভাবে আপনি কোনও ইন্টারফেসের উপর বিশৃঙ্খলা না করে নির্ভর করতে পারেন? আমি মনে করি ভিউ মডেলগুলি দুর্দান্ত ..
দ্য মফিন ম্যান

12

ওয়েবে, প্রত্যেকে তাদের ডিকোপলিং এমভিসি কল করে।

কিছু প্রযুক্তি, যেমন সি #, এমভিভিএম ব্যবহার করে কারণ ভিউ এবং অন্য কোনওটির মধ্যে কোনও লিঙ্ক নেই, ভেরিয়েবলগুলি আবদ্ধ করে পরিষেবা সার্ভিস লোকেটার দিয়ে সবকিছু যায়।

খাঁটি এমভিসি-তে, ভিউ সরাসরি মডেল এবং তদ্বিপরীতদের সাথে কথা বলে। নিয়ামক কেবল তখনই থাকে যখন কোনও পরিবর্তন ঘটে।

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

আপনি এখানে আরও ভাল উপায় দেখতে পাবেন: http://www.garfieldtech.com/blog/mvc-vs-pac


7

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

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


6

ইন MVC , পল Hegarty ভুল। নিয়ামক ব্যবহারকারীর ইভেন্টগুলি সম্পর্কে, মডেল থেকে দেখার যোগাযোগ নয়। শাস্ত্রীয় এমভিসিতে , ভিউ (গুলি) মডেল (পর্যবেক্ষক নিদর্শন) পর্যবেক্ষণ করে।

মধ্যস্থতা করার মধ্যবর্তী লোকটির সাথে, প্যাটার্নটিকে এমভিপি বলা উচিত এবং বাস্তবে, বর্তমানে যা বেশিরভাগই এমভিসি হিসাবে উপস্থাপিত হয়, বেশিরভাগই আসলে এমভিপির নিকটবর্তী।

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


1
আজ (২০১৪ শুরুর দিকে), আমার কাছে (আমার নোড এবং কৌণিক স্ট্যাকের সাথে) "ক্লায়েন্ট" এমভিসি এবং "সার্ভার" এমভিসি-তে এই পার্থক্যটি অত্যন্ত প্রাসঙ্গিক এবং একরকম আলোকিত বলে মনে হচ্ছে। (আপনাকে ধন্যবাদ)
স্ল্যাকট্রেসার

4

যেহেতু আপনি বিশেষত স্ট্যানফোর্ডের বক্তৃতাগুলির উপাদানগুলি সম্পর্কে জিজ্ঞাসা করছেন, তাই হেগার্টির অবস্থান সম্পর্কে দুটি বিষয় বিবেচনা করার মতো:

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

1

আমি পল হেগার্টির সাথে একমত এবং বিশ্বাস করি যে ভিউটি অবশ্যই মডেল সম্পর্কে জানেন না। এটি অর্জন করা এত কঠিন নয় তবে এটি আপনার নকশা এবং ভবিষ্যতের নমনীয়তার জন্য অতিরিক্ত বেনিফিট নিয়ে আসে।

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

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

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


1

আমি বিশ্বাস করি যে এর পক্ষে কঠোর এবং দ্রুত কোনও নিয়ম নেই, এটি সম্পূর্ণ আপনার প্রয়োজনের উপর নির্ভর করে।

আপনি বিভিন্ন বিশ্বাসের লোকদের খুঁজে পাবেন। আর্কিটেকচারগুলি আরও ভাল সমাধানগুলি ডিজাইন করতে সহায়তা করার ধারণা are

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

এগুলি ছাড়াও ব্যবসায় যুক্তিটিকে অ্যাপ্লিকেশন লজিক (এটি নিয়ন্ত্রণকারীর উপর রাখুন) এবং ডোমেন লগইনকে (এটি মডেলে রাখুন) বিভক্ত করার সম্ভাবনা রয়েছে।

সুতরাং, গল্পটির নৈতিকটি এমভিসি মানে মডেল, ভিউ এবং নিয়ামক পৃথক হওয়া উচিত। এটি বাদে, আপনার পক্ষে যেটি উপযুক্ত।


0

আমি মডেল-ভিউ যোগাযোগের জন্য ডিটিও ব্যবহার করি।

এই ক্ষেত্রে:

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

-1

আমি সেই শিবিরের সাথে আছি যা বলে যে ভিউটি কখনও মডেলের সাথে যোগাযোগ করা উচিত নয়। নিয়ামককে সর্বদা সর্বদা যেতে যাওয়া লোক হতে হবে, তারপরে সিদ্ধান্ত নেবে কী করবেন (বৈধতা দিন, মডেল থেকে ডেটা চাইতে হবে ইত্যাদি)।

আমি এটিকে আরও সাংগঠনিক সমস্যা হিসাবে দেখতে চাই যে অন্য কিছু।


-1

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

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

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

আইওএসে কারা ছোট ভিউকন্ট্রোলার খুঁজছেন তাদের সহায়তা করতে পারে:

http://blog.xebia.com/simplification-of-ios-view-controllers-mvvm-or-presentation-controls/

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