পরিষ্কার আর্কিটেকচার: ভিউ মডেল কী?

Question

তাঁর 'ক্লিন আর্কিটেকচার' বইয়ে আঙ্কেল বব বলেছেন যে উপস্থাপকের যে তথ্যটি পাওয়া যায় সেটিকে এমন কিছুতে রাখা উচিত যা তাকে 'ভিউ মডেল' বলে।

এটি কি মডেল-ভিউ-ভিউমোডেল (এমভিভিএম) ডিজাইন প্যাটার্ন থেকে 'ভিউমোডেল' হিসাবে একই জিনিস বা এটি কোনও সাধারণ ডেটা ট্রান্সফার অবজেক্ট (ডিটিও)?

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

আমার ধারণা এটি এমভিভিএমের ভিউমোডেলের মতোই, কারণ তাঁর বইয়ের রবিবার মার্টিন বলেছেন:

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

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

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

এটি যদি কোনও ডিটিও না হয় বা এমভিভিএম থেকে ভিউমোডেল না হয়, তবে দয়া করে এটি কী তা বিস্তারিতভাবে বর্ণনা করুন।

Comments

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

— গ্রেগ বার্গার্ট

এমভিভিএম (ডাব্লুপিএফ, উইনফর্মস অ্যাপ্লিকেশন) এর ViewModelজন্য মোড়কযুক্ত Controller, Presenterএবং ViewModelচাচা ববসের ক্লিন আর্কিটেকচারে।

— ফ্যাবিও

@ গ্রেগ বার্গার্ড্ট - যখন ভিউমোডেল একটি বিশেষায়িত ডেটা কাঠামো হয়, তবে পরিবর্তনের বিষয়ে ভিউ কীভাবে জানানো হয়?

— Fearnbuster

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

— ফের্নবাস্টার

আমি মনে করি তিনি ইনপুট এবং আউটপুট হ্যান্ডলারগুলিকে বিভিন্ন বস্তু / শ্রেণিতে পৃথক করেছেন। এমভিভিএম এ এটি Controller-> ICommandএবং Presenter-> হতে পারে data-binding mechanism।

— ফ্যাবিও

Answer 1

এটি কি মডেল-ভিউ-ভিউমোডেল (এমভিভিএম) ডিজাইন প্যাটার্ন থেকে 'ভিউমোডেল' হিসাবে একই জিনিস

নাঃ।

যে হবে এই :

তার চক্র রয়েছে। চাচা বব সাবধানে চক্র এড়ানো হয়েছে ।

পরিবর্তে আপনার এটি আছে:

যার অবশ্যই চক্র নেই। তবে এটি আপনাকে কীভাবে কোনও আপডেট সম্পর্কে জানে তা ভাবছে। আমরা এক মুহুর্তে এটি পেয়ে যাব।

বা এটি একটি সাধারণ ডেটা ট্রান্সফার অবজেক্ট (ডিটিও)?

পূর্ববর্তী পৃষ্ঠা থেকে ববকে উদ্ধৃত করতে:

আপনি যদি পছন্দ করেন তবে আপনি বেসিক স্ট্রাকস বা সাধারণ ডেটা ট্রান্সফার অবজেক্ট ব্যবহার করতে পারেন। অথবা আপনি এটি একটি হ্যাশম্যাপে প্যাক করতে পারেন, বা এটি কোনও বস্তুতে তৈরি করতে পারেন।

পরিষ্কার আর্কিটেকচার p207

সুতরাং, নিশ্চিত, যদি আপনি চান।

কিন্তু আমি দৃঢ়ভাবে সন্দেহ কি সত্যিই আপনি bugging হল এই :

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

ব্যবহারের সম্পর্কের ক্ষেত্রে:

নিয়ন্ত্রণের প্রবাহ একই কোডে চলে যায় উত্স কোড নির্ভরতা।

একটি বাস্তবায়ন সম্পর্কের ক্ষেত্রে:

নিয়ন্ত্রণের প্রবাহ সাধারণত উত্স কোড নির্ভরতা বিপরীত দিকে যায়।

যার অর্থ আপনি সত্যই এটি দেখছেন:

আপনি দেখতে সক্ষম হবেন যে নিয়ন্ত্রণের প্রবাহ উপস্থাপক থেকে ভিউতে কখনও যায় না।

কিভাবে এটা পারব? এর মানে কী?

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

যদি এটি একই থ্রেড হয় তবে ভিউ-মডেলটি কখন পড়তে প্রস্তুত তা ভিউটি জানতে পারবে। তবে যদি এটির ক্ষেত্রে এবং ভিউটি জিইউআই হয় তবে ব্যবহারকারীরা ডিবিটির জন্য অপেক্ষা করার সময় ব্যবহারকারী যখন এটিকে ঘুরিয়ে ফেলবে তখন পর্দাটি পুনরায় রঙ করতে বেশ অসুবিধা হবে।

যদি ভিউটির নিজস্ব থ্রেড থাকে তবে এর নিজস্ব নিয়ন্ত্রণের প্রবাহ থাকে। এর অর্থ এটি বাস্তবায়নের জন্য ভিউকে পরিবর্তনগুলি লক্ষ্য করার জন্য ভিউ-মডেলটি পোল করতে হবে।

যেহেতু উপস্থাপক জানেন না ভিউটি বিদ্যমান এবং ভিউটি জানেন না যে উপস্থাপক উপস্থিত রয়েছে তারা একে অপরকে কল করতে পারে না। তারা একে অপরকে ঘটনার ঝাঁকুনি দিতে পারে না। যা ঘটতে পারে তা হ'ল উপস্থাপক ভিউ-মডেলটিতে লিখবেন এবং ভিউটি ভিউ-মডেলটি পড়বে। এটি যখনই মনে হয়।

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

এটি অসম্ভব বলে মনে হতে পারে তবে ভিউ-মডেলটি জটিল হলেও এটি কাজ করা যায়। একটি সামান্য আপডেট হওয়া ক্ষেত্র হ'ল পরিবর্তনটি সনাক্ত করতে সমস্ত দৃশ্যই পোল করতে হবে।

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

নিয়ন্ত্রণের প্রবাহটি চিত্রিত করে আমি এখানে কিছুটা মজাদার:

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

কেবল এখানে অন্য কিছু শিখতে হবে তা হ'ল ব্যবহারের কেস ইন্টারেক্টর যতক্ষণ না উপস্থাপককে শেষ বলবে ততক্ষণ যেকোন ক্রমে এটি কল করতে পারে।

Comments

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

— ফের্নবাস্টার

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

— candied_orange

ঠিক আছে, সহায়তার জন্য অনেক ধন্যবাদ। যদি / আপনি এই আর্কিটেকচারটি অনুসরণ করেন, আপনি কি সাধারণত প্রযুক্তি ব্যবহার করেন?

— Fearnbuster

আমি মনে করি যে এখানে বড় ভুল রয়েছে যে এই উত্তরগুলি একত্র করে নির্ভরতা এবং রানটাইম নির্ভরতা তৈরি করে। দুটি আলাদা হতে পারে।

— ইউফোরিক

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

— candied_orange

Answer 2

আমি এই সমস্যাটি খুব বিভ্রান্তিকর বলে মনে করি এবং সমস্যাটি সঠিকভাবে ব্যাখ্যা করতে অনেকগুলি পাঠ্য ও সময় লাগবে কারণ আমার বিশ্বাস আপনি মার্টিনের ক্লিন আর্কিটেকচার এবং এমভিভিএম উভয়কেই ভুল বোঝেন।

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

অর্কেস্টেটর কোড হিসাবে সহজ হবে

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

আমি বিশ্বাস করি ক্লিন আর্কিটেকচার সম্পর্কে তার একটি আলোচনায় আমি মার্টিনকে এই বিষয়ে কথা শুনেছি।

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

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

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

বিপরীতে ViewModelক্লিন আর্কিটেকচারে কোনও যুক্তি ছাড়াই কেবল সরল ডিটিও। এটি <DS>ট্যাগ দ্বারা সুস্পষ্ট করা হয় । এবং orchestratorএটি প্রয়োজনীয় কারণ কেন এটি Viewকখন যুক্তিযুক্ত তা চালানো যায় না।

আমি রানটাইমের সময় চিত্রটি কেমন দেখায় তা "সমতল" করাতে থাকলে এটি দেখতে এই রকম দেখাবে:

সুতরাং রানটাইম চলাকালীন নির্ভরতাগুলি "ভুল" দিকের দিকে থাকে তবে তা ঠিক।

আমি তার যুক্তি আরও ভালভাবে বুঝতে ক্লিন আর্কিটেকচার সম্পর্কে তাঁর আলোচনা দেখার পরামর্শ দিই ।

Comments

আপনার "অর্কেস্টেটর" উপস্থাপককে কল করা উচিত নয়। ইউজ কেস ইন্টারেক্টর এটি করে।

— candied_orange

@ ক্যান্ডিড_আরঞ্জ সত্য, এটি একটি ভুল।

— ইউফোরিক

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

— Fearnbuster

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

— ইউফোরিক

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

— Fearnbuster