মডেল-ভিউ-উপস্থাপক বাস্তবায়ন চিন্তাভাবনা

34

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

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

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

আমি চেষ্টা করছি:

এটি যতটা সম্ভব decoupled করা
উপস্থাপনা / মডেলটিকে অন্য ভাষার দর্শনগুলির সাথে জুড়ে দেওয়া আদর্শভাবে তৈরি করুন (আমি একটি টন আন্ত-ভাষার সামগ্রীর কাজ করিনি, তবে আমি জানি এটি সম্ভব, বিশেষত void(void)কমপক্ষে একটি সি # অ্যাপ্লিকেশন দিয়ে আমি আরও বেশি আটকে থাকতে পারি) সি ++ লাইব্রেরি ...
কোডটি পরিষ্কার এবং সরল রাখুন

সুতরাং .. কোনও পরামর্শ কীভাবে ইন্টারঅ্যাকশনগুলি পরিচালনা করা উচিত?

design-patterns ui interfaces

— ধরার চেষ্টা কর
সূত্র

আপনি কি এই নিবন্ধটি দেখেছেন ?: en.wikedia.org/wiki/Model-view- presenter

— বার্নার্ড

1

আমি .. আমি একটু দ্রুত এবং উচ্চ পর্যায়ে পাওয়া যায় নি, আমি ভাল কিভাবে একটি বৃহৎ প্রকল্পে একাধিক ডায়ালগ হ্যান্ডেল বুঝতে অপেক্ষায় থাকবো সঙ্গে যতটা সম্ভব সামান্য সংযোজন .. যেমন

— trycatch

37

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

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

এটি করার অনেকগুলি উপায় রয়েছে। প্রতিটি ডায়ালগ / ফর্মকে ভিন্ন দৃষ্টির সাথে বিবেচনা করে পরিচালনা করা এটি দেখতে খুব সাধারণ। অনেক সময় দেখা ও উপস্থাপকদের মধ্যে 1: 1 সম্পর্ক রয়েছে। এটি কোনও কঠোর, দ্রুত নিয়ম নয়। একজন উপস্থাপক একাধিক সম্পর্কিত মতামত বা তদ্বিপরীত পরিচালনা করতে এটি বেশ সাধারণ। এটি সমস্ত দৃষ্টিভঙ্গির জটিলতা এবং ব্যবসায়িক যুক্তির জটিলতার উপর নির্ভর করে।

মতামত এবং উপস্থাপকরা একে অপরের সাথে রেফারেন্স কীভাবে পান, এটিকে কখনও কখনও তারেরও বলা হয় । আপনার তিনটি পছন্দ রয়েছে:

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

MyForm.SomeEvent(Sender)
{
  Presenter.DoSomething(Sender.Data);
}

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

উপস্থাপকটি দেখার জন্য একটি রেফারেন্স ধারণ
করে দৃশ্যে ভিউটি ব্যবহারকারীর কাছে প্রদর্শিত ডেটার জন্য বৈশিষ্ট্যগুলি প্রকাশ করে। উপস্থাপক ইভেন্টগুলির জন্য শোনেন এবং ভিউটিতে বৈশিষ্ট্যগুলি পরিচালনা করেন:

Presenter.SomeEvent(Sender)
{
  DomainObject.DoSomething(View.SomeProperty);
  View.SomeOtherProperty = DomainObject.SomeData;
}

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

View.SomeEvent(Sender)
{
  Presenter.DoSomething();
}

Presenter.DoSomething()
{
  View.SomeProperty = DomainObject.Calc(View.SomeProperty);
}

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

— কেনেথ কোচরান
সূত্র

1

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

— চেষ্টা করুন

8

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

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

এখানে একটি উদাহরণ। প্রথমে ব্যবহারকারীর কাছে একটি বার্তা প্রদর্শন করার জন্য আমাদের একটি সাধারণ পদ্ধতি সহ একটি ভিউ ক্লাস রয়েছে:

interface IView
{
  public void InformUser(string message);
}

এখন এখানে উপস্থাপক। নোট করুন যে উপস্থাপক একটি আইভিউতে এর কনস্ট্রাক্টরে নিয়ে যায়।

class Presenter
{
  private IView _view;
  public Presenter(IView view)
  {
    _view = view;
  }
}

এখন আসল ইউজার ইন্টারফেস এখানে। এটি উইন্ডো, একটি ডায়ালগ, একটি ওয়েব পৃষ্ঠা ইত্যাদি হতে পারে matter দ্রষ্টব্য দ্রষ্টব্যর জন্য নির্মাণকারী এতে ইনজেকশনের মাধ্যমে উপস্থাপক তৈরি করবে।

class View : IView
{
  private Presenter _presenter;

  public View()
  {
    _presenter = new Presenter(this);
  }

  public void InformUser(string message)
  {
    MessageBox.Show(message);
  }
}

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

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

class Presenter
{
  public void DoSomething()
  {
    _view.InformUser("Starting model processing...");
  }
}

আপনি এখানে আপনার decoupling পেতে। উপস্থাপক কেবল আইভিউ বাস্তবায়নের জন্য একটি রেফারেন্স রাখেন এবং কীভাবে এটি বাস্তবায়িত হয় তা যত্নবান নয়।

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

— বিল সিমসার
সূত্র

4

আমি মনে করি যে কন্ট্রোলার / উপস্থাপক সেই জায়গাটিই সত্যই কার্যকর হয় যেখানে এটি মনে রাখা গুরুত্বপূর্ণ। প্রয়োজনীয়তার কারণে নিয়ামক মধ্যে সংযোজন অনিবার্য।

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

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

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

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

— ফিলিপ রেগান
সূত্র

এটি অবশ্যই আমার লক্ষ্য। আমার মূল সমস্যা হল কীভাবে ভিউ সেট আপ করতে হয় - এটি প্রতিটি সংলাপের উদাহরণ সহ একটি শ্রেণি হওয়া উচিত এবং তারপরে View.Getters কে ডায়লগ.গেটার্স কল করে, বা উপস্থাপক যদি ডায়লগ ডেকে নিতে সক্ষম হয় G এটি খুব

— দৃly়ভাবে একত্রে

আমি মনে করি উপস্থাপক / নিয়ন্ত্রণকারী দর্শনগুলির জন্য পুরোপুরি দায়বদ্ধ হওয়া উচিত, সুতরাং পরবর্তীটি। আবার কিছু সংযোগ সংঘটিত হতে বাধ্য, তবে যদি কমপক্ষে দায়িত্বের দিকটি পরিষ্কার থাকে তবে দীর্ঘমেয়াদে রক্ষণাবেক্ষণ আরও সহজ হওয়া উচিত।

— ফিলিপ রেগান

2

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

— 22-21

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

— ফিলিপ রেগান

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

— মার্সেল টথ

2

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

এই কোডটির জন্য আপনার পরীক্ষাটি স্বয়ংক্রিয় করা সহজ
এটি সমস্ত গুরুত্বপূর্ণ জিনিস এক জায়গায় রাখে

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

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

সাধারণ নীতিটি প্রকৃত ক্লাসে ম্যাপিং

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

— বেরিন লরিটস
সূত্র