একটি এমভিসি আর্কিটেকচারে, কন্ট্রোলারের কাছে মডেল এবং দর্শন কতটা ঘনিষ্ঠভাবে মিলিত হয়?

Question

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

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

Comments

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

— স্টিভেন ইভার্স

@ এসএনআরফাস: আমি যা ভেবেছিলাম তার ঠিক বিপরীত- এম ও ভি সি-র সাথে মিলিত হয়েছে তবে একে অপরের সাথে নয়।

— ডেড এমজি

এত উত্তর কিভাবে ভুল হতে পারে। এখানে মাইক্রোসফট এর সংস্করণ পড়তে msdn.microsoft.com/en-us/library/ff649643.aspx

— Reactgular

এই নিবন্ধটি একটি পঠন দিন: অবজেক্টমোটার

— এডওয়ার্ড স্ট্রেঞ্জ

Answer 1

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

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

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

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

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

.NET বিশ্বে, আমরা এমন কিছু না ঘটানোর অনুমতি না দিয়ে ঝুঁকি হ্রাস করার প্রবণতা করি এবং সম্ভবত সেই কারণেই, আমার কাছে মনে হয় যে বিচ্ছিন্ন দৃষ্টিভঙ্গি মডেলটি আরও জনপ্রিয়।

Comments

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

— কোডার্ট

Answer 2

দ্রষ্টব্য: রবার্ট সি মার্টিন (ওরফে আঙ্কেল বব) তার মূল বক্তব্য, আর্কিটেকচার দ্য লস্ট ইয়ার্স-এ এটি আরও ভাল এবং হাস্যকর উপায়ে ব্যাখ্যা করেছেন । কিছুটা লম্বা তবে প্রচুর ভাল ধারণা শেখায়।

tl; dr: আপনার অ্যাপ্লিকেশনটিকে এমভিসির ক্ষেত্রে বিবেচনা এবং পরিকল্পনা করবেন না। এমভিসি কাঠামো কেবল একটি বাস্তবায়ন বিশদ।

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

কাঠামোর শর্তে নয়, কোনও প্রোগ্রামের শর্তে চিন্তা করার চেষ্টা করুন।

আপনার প্রোগ্রামটির একটি উদ্দেশ্য রয়েছে। এটি কিছু ডেটা নেয়, ডেটা দিয়ে জিনিস করে এবং কিছু ডেটা দেয়।

এইভাবে, controllerআপনার প্রোগ্রামের বিতরণ প্রক্রিয়া mechanism

1. একজন ব্যবহারকারী আপনার প্রোগ্রামে একটি অনুরোধ প্রেরণ করে (আসুন বলে নেওয়া যাক, শপিং কার্টে একটি পণ্য যুক্ত করুন)।
2. নিয়ামক সেই অনুরোধটি (পণ্যের তথ্য এবং ব্যবহারকারীর তথ্য) নেয়, এটি আপনার প্রোগ্রামের প্রয়োজনীয় অংশকে কল করে যা এই অনুরোধটি পরিচালনা করবে $user->addToCart($product)
3. আপনার প্রোগ্রাম ( এই ক্ষেত্রে অবজেক্টের addToCartক্রিয়াকলাপ user) তার কাজটি করা কাজটি করে এবং একটি প্রতিক্রিয়া ফিরিয়ে দেয় (আসুন বলি success)
4. নিয়ামক প্রাসঙ্গিক ব্যবহার করে প্রতিক্রিয়া প্রস্তুত করে view: যেমন। নিয়ামক বস্তুতে$this->render($cartView('success')

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

আপনি যদি অন্য কাঠামো ব্যবহার করতে চান তবে আপনার অ্যাপ্লিকেশনটির পরিবর্তনের প্রয়োজন হবে না, অনুরোধের জন্য আপনার প্রোগ্রামটি কল করার জন্য আপনাকে কেবল প্রাসঙ্গিক কন্ট্রোলার লিখতে হবে।

অথবা আপনি যদি কোনও ডেস্কটপ সংস্করণ বানাতে চান তবে আপনার অ্যাপ্লিকেশনটি একই থাকবে, আপনার কেবল বিতরণ প্রক্রিয়া প্রস্তুত করতে হবে।

এবং Model। এটি একটি অধ্যবসায় প্রক্রিয়া হিসাবে ভাবেন।

ওও উপায়ে, আপনার প্রোগ্রামে এমন কিছু জিনিস রয়েছে যা ডেটা ধরে রাখে।

class User {
    //...
    private $id;
    private $shoppingCart;
    //...
}

class Product {
    //...
    private $id;
    //...
}

আপনি শপিং কার্ট একটি পণ্য যোগ করেন, তখন আপনি যোগ করতে পারেন product::idথেকে user::shoppingCart।

এবং যখন আপনি ডেটা অবিরাম রাখতে চান, তখন আপনি modelকাঠামোর অংশটি ব্যবহার করতে পারেন , যা সাধারণত একটি ORM ব্যবহার করে থাকে, ডাটাবেস সারণিতে ক্লাসগুলি মানচিত্র করতে।

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

---

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

Comments

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

— এডওয়ার্ড স্ট্রেঞ্জ

হ্যাঁ, আমি লিখলাম যেভাবে লোকেরা কী কী তা ভাববে MVC। এজন্যই আমি লিখেছি MVC Framework।

— হাকান ডেরিয়াল

Answer 3

মার্টিন ফোলার এমভিসি দৃষ্টান্ত বর্ণনা করার জন্য একটি ভাল কাজ করেন। এখানে তার নিবন্ধটির লিঙ্কটি এখানে রয়েছে: http://martinfowler.com/eaaDev/uiArchs.html

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

Answer 4

এমভিসি কীভাবে একটি সাধারণ জাভা সুইং অ্যাপ্লিকেশনটিতে ব্যবহার করা যায় তার একটি সাধারণ উদাহরণ এখানে ...

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

এটি হ'ল সাধারণ এমভিসি অ্যাপ্লিকেশন দ্বারা গৃহীত আদর্শ পদ্ধতির ...

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

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

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

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

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

Answer 5

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

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

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

মূলত, কন্ট্রোলারটি ইন্ডিয়ারেশনের স্তর যা মডেল থেকে দর্শনকে হ্রাস করে, যাতে একে অপরের সম্পর্কে তাদের জানতে না হয়।

Comments

আহ - এ কারণেই ডাউনটিভোটস - আমি ভুল লিখেছি। আমি বোঝাতে চাইছি কন্ট্রোলারের উভয়েরই নির্ভরতা রয়েছে। ডি আহা!

— ম্যাথু ফ্লিন 18

Answer 6

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

ভিউটি দম্পতিরা যা কিছু দেখছে তার সাথে মিলিত হয়, যা বোঝা যায়। এমন দৃশ্যের সাথে আসা শক্ত যে এটি যা দেখছে তা থেকে ডিকপল হতে পারে ... তবে কখনও কখনও আপনার কাছে আংশিক মিলন বা কিছু থাকতে পারে।

নিয়ামক প্রায়শই দুজনের মধ্যে জুড়ি থাকে। ঘটনাটি মডেল পরিবর্তনে রূপান্তরিত করা কাজটি হওয়ায় এটি কিছুটা অর্থপূর্ণও হয়।

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

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

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

মূলত, এমভিসি-র সমাধানের জন্য যা কিছু বোঝানো হয়েছিল তা এখন উইজেটের অভ্যন্তরে ঘটে এবং এমন কিছু যা আমাদের আর ব্যবহার করতে হয় না।

---

যারা মনে করেন তারা আরও ভাল জানেন:

http://www.codeproject.com/Articles/42830/Model-View-Controller-Model-View-Presenter-and-Mod

http://msdn.microsoft.com/en-us/library/ff649643.aspx

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

তবে কেন আসুন তথ্যগুলি ...

ইতিমধ্যে অন্য উত্তরে পোস্ট করা একটি নিবন্ধও আমার বক্তব্যকে সমর্থন করে:

http://martinfowler.com/eaaDev/uiArchs.html

লোকেরা যদি বলতে থাকে যে ডিজাইন শিল্পের প্রত্যেকটিই ভুল, তবে এটি ঠিক আছে।

Comments

এটা স্পষ্টতই ভুল। কোনও মডেল অবশ্যই কোনও দৃশ্যের উপর নির্ভর করে না! এমনকি যদি এই দৃশ্যটি বিমূর্ত বা একটি ইন্টারফেস হয়। একটি মডেল উপস্থাপনা থেকে পুরোপুরি decoupled করা উচিত!

— ফ্যালকন

উত্তরটি ভুল। মডেল কোনও ভিউ বা নিয়ামকের উপর নির্ভর করে না।

— কোডার্ট

@ ক্রেজি এডি আপনি বলেছেন: "আমার অভিজ্ঞতায় সাধারণত মডেলটি কেবল একটি পর্যবেক্ষকের উপর নির্ভর করে, নির্দিষ্ট কোনও নয়, প্রায়শই একজন পর্যবেক্ষক হিসাবে" আপনার উদ্ধৃত রেফারেন্সটি বলে: "তবে মডেলটি ভিউ বা নিয়ামকের উপর নির্ভর করে না।" আপনি কি উদ্ধৃত নিবন্ধটি পড়েছেন? দেখে মনে হচ্ছে না।

— কোডার্ট

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

— ফ্যালকন

@ ক্র্যাজি এডি: লোহিত @ ডাউনভোট রাস্তায়। আমি কি রেগে গেছি?

— ফ্যালকন

Answer 7

• নিয়ামক একটি দৃশ্যে মডেল প্রেরণ করেন এবং এটি ভিউগুলি থেকে জমা দেওয়া মডেলটি প্রসেস করে, তবে এটি দৃশ্যের সাথে বা কোনও মডেলের সাথে শক্তভাবে মিলিত হয় না।

যদি নিয়ামক দৃশ্যের সাথে দৃশ্যের সাথে মিলিত হয় তবে আমরা ওয়েব ফর্মের জগতে থাকব। আপনার একটি কোড থাকবে যার পেছনে কোনও টেমপ্লেট ফাইলে বাঁধা থাকবে (ASP.NET ওয়েব ফর্মের জন্য প্রযোজ্য)

এ কারণে, নিয়ামক কোনও মডেল বা দৃশ্যের সাথে মিলিত হয় না। এটি কেবল অনুরোধগুলি প্রক্রিয়া করার জন্য এবং প্রতিক্রিয়াগুলি প্রেরণের জন্য একটি প্রক্রিয়া।

• দৃশ্যের সাথে দৃ .়ভাবে একটি মডেলের সাথে মিলিত হয়। আপনার মডেলটিতে পরিবর্তন করুন (উদাহরণস্বরূপ এটির সম্পত্তি পরিবর্তন করুন) এবং আপনাকে আপনার ভিউতে পরিবর্তন আনতে হবে।

• মডেল দৃশ্যের সাথে দৃশ্যের সাথে মিলিত হয় না। একটি দর্শন পরিবর্তন করুন, এবং এটি একটি মডেল উপর প্রভাব ফেলবে না।

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

এই সম্পর্কে চিন্তা করার আরেকটি উপায়:

• কোনও নিয়ামককে পরিবর্তন করুন - দেখুন এবং মডেলটি প্রভাবিত হবে না

• কোনও মডেলটিতে পরিবর্তন আনুন - এটি কোনও মডেলটির উপর নির্ভর করে দেখায় ভঙ্গ হবে

• একটি দৃশ্যে পরিবর্তন করুন - মডেল এবং নিয়ামক প্রভাবিত হবে না

এমভিসি প্রকল্পগুলিতে এই আলগা সংযোগটি ইউনিট পরীক্ষায় তাদের সহজ করে তোলে।

Comments

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

— আয়তাকার

@ ম্যাথিউফোস্কারিণী কান্না থামিয়ে একটি "সঠিক উত্তর" রেখে দিন

— কোডার্ট

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

— ই

আমি আপনার জন্য আরও তথ্য রেখেছি, আশা করি এটি উপলব্ধি হয়ে যাবে

— কোডার্ট