এমভিসি কি বিরোধী ওওপি নয়?

61

OOP এর পিছনে মূল ধারণাটি হ'ল একক সত্তা - অবজেক্টে ডেটা এবং আচরণকে একত্রিত করা। পদ্ধতিগত প্রোগ্রামিংয়ে ডেটা থাকে এবং পৃথকভাবে ডেটা সংশোধন করে থাকে অ্যালগরিদম।

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

design object-oriented mvc

— m3th0dman
সূত্র

11

তাদের কেন একই যৌক্তিক সত্তায় থাকতে হবে? কেন আপনি সুবিধাজনক হবেন না বা OOP কেন এই ব্যবস্থাটি আদেশ করবেন তা আপনি বলেননি।

— রবার্ট হার্ভে

26

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

— রবার্ট হার্ভে

2

কি? একত্রে ডেটা এবং আচরণকে একীকরণ করা ঠিক ওওপি-র সম্পর্কে।

— অ্যান্ডি

3

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

— কাজ

5

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

— কাজ

44

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

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

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

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

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

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... এবং সেই আচরণ মুদ্রা অবজেক্টের সাথে আবদ্ধ হবে।

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

সুতরাং আচরণটি কোনও Tellerবস্তুর মধ্যে আবদ্ধ হয়ে যায় এবং এটি গ্রহণ করে Currencyএবং Accountইনপুট হিসাবে বস্তুগুলি গ্রহণ Transactionকরে তবে ইনপুট অবজেক্টগুলিকে প্রক্রিয়া করতে সহায়তা করার জন্য কিছুটা স্থানীয় রাজ্য (বা হতে পারে কোনও বস্তু) ব্যতীত এটি কোনও তথ্য নিজেই ধারণ করে না ।

— রবার্ট হার্ভে
সূত্র

এবং কোন সত্তা / প্যাকেজের Tellerমধ্যে স্থাপন করা উচিত ? ইন Controllerকোথা থেকে Teller'sমেথড কল করা হয় বা Modelব্যবসা লজিক অংশ কারণ এটি কি?

— m3th0dman

TellerModelএটি কন্ট্রোলার থেকে কল করা যেতে পারে যদিও, যায় । এটি ব্যবসায়ের ডোমেনের একটি অংশ।

— রবার্ট হার্ভে

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

— ইয়াম মার্কোভিচ

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

— রবার্ট হার্ভে

4

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

— এরিক পুনরায়

73

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

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

— মাইকেল বর্গওয়ার্ট
সূত্র

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

— m3th0dman

6

@ এম থ্রিডিডম্যান: আপনি বিস্তৃত, ঝাড়ু সাধারণের মধ্যে কথা বলছেন। কীভাবে এমভিসি উইংফর্মস বা ওয়েবফর্মগুলি যে স্প্যাগেটি-কোড দুঃস্বপ্নকে সরিয়ে দেয়, যেমন সুনির্দিষ্টভাবে আলোচনা করার বিষয়ে?

— রবার্ট হার্ভে

3

@ এম থ্রিডিডম্যান: এটি ডিডিডির একটি দুর্দান্ত সরল বৈশিষ্ট্য।

— মাইকেল বর্গওয়ার্ট

1

@ রবার্তাহারভেটি নিশ্চিত করে নিন যে এমভিসি কেন ভাল তা আপনি পাল্টা পয়েন্ট হচ্ছেন কারণ স্প্যাগেটিটি দূরে সরিয়ে দেওয়ার বিষয়টি এখানে আসলে প্রতিযোগিতায় নেই। আমি সম্মত তবে আমি পদ্ধতিগত প্যাটার্নে এমভিসি বাস্তবায়িতও দেখতে চাই। সুতরাং আমি মনে করি এটি জিজ্ঞাসা করার জন্য একটি প্রাসঙ্গিক প্রশ্ন, বা বরং- সম্ভবত জিজ্ঞাসা করা প্রশ্নটি হল "লোকেরা এমভিসি পদ্ধতিগতভাবে কতবার প্রয়োগ করে?"

— জিমি হোফা

1

@ রবার্ট হার্ভে প্রশ্নের উদ্দেশ্য এমভিসি কতটা ভাল বা খারাপ তা নয়; এটি ওও নীতির উপর ভিত্তি করে বা না ভিত্তিক।

— m3th0dman

71

OOP প্রত্যেকের নিজস্ব ডেটা এবং তাদের নিজস্ব আচরণ রয়েছে এমন অবজেক্টগুলির মধ্যে মিথস্ক্রিয়াকে সীমাবদ্ধ করে না।

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

— dasblinkenlight
সূত্র

5

+1: আমি সাধারণত উপমাগুলির মাধ্যমে ব্যাখ্যাগুলি অপছন্দ করি তবে এটি দুর্দান্ত one

— মাইকেল বর্গওয়ার্ট

@ কালেব এটি একটি দুর্দান্ত পয়েন্ট, আপনাকে অনেক ধন্যবাদ!

— dasblinkenlight

19

ওওপি উদ্বেগের বিচ্ছেদ সম্পর্কেও রয়েছে , তা হ'ল বিভিন্ন বস্তুতে বিভিন্ন ভূমিকা / দায়িত্ব পৃথক করা।

এমভিসি এই উপাদানগুলিতে পৃথক হয়:

মডেল: ডেটা এবং তার ব্যবসায়িক যুক্তি
দেখুন: তথ্য উপস্থাপনা
নিয়ামক: মডেল এবং দর্শনের মধ্যে সমন্বয়।

সুতরাং এই দায়িত্বগুলি স্পষ্টভাবে স্বতন্ত্র এবং প্রকৃতপক্ষে একাধিক সত্তায় বিভক্ত হওয়া উচিত।

— মার্কো-fiset
সূত্র

এটি সত্য যে একক দায়িত্বের নীতিটি কার্যকরভাবে ওওপি ব্যবহারে কার্যকর, তবে আমি মনে করি যে এটি "ওওপিও একক দায়িত্বের নীতি সম্পর্কেও বলেছে" a পিছনে মনে হচ্ছে।

— কালেব

@ কালেব হ্যাঁ, আপনি কী বলতে চাইছেন তা আমি বুঝতে পেরেছি। হতে পারে এটি পুনঃস্থাপন করা যেতে পারে তবে আপনি পয়েন্টটি পান।

— মার্কো ফিসেট

18

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

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

এটি এইভাবে চিন্তা করুন: যদি বস্তুগুলি এনক্যাপসুলেশন না ভেঙে পিছনে পিছনে ডেটা পাস করতে না পারে, তবে সত্যিকার অর্থে আপনার কেবল একটি অবজেক্ট থাকতে পারে!

সমতুল্য ওওপি পদ্ধতির ক্ষেত্রে মডেল এবং নিয়ামকটিকে একই লজিক্যাল সত্তায় স্থাপন করা উচিত নয়?

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

— কালেব
সূত্র

আমি আশা করব যে নিয়ামকের যুক্তি রয়েছে তবে কোনও অবস্থাতেই সামান্য। আপনি কন্ট্রোলারের কী ধরণের রাষ্ট্রের কথা ভাবছেন?

— ম্যাথিউ ফ্লিন

1

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

— কালেব

1

@ ম্যাটফেনউইক 'ফ্লেভার' সম্পর্কে আমি যা বোঝাতে চাইছি ... আপনি নিয়ামকটিতে ঠিক কী সঞ্চয় করেন এবং মডেলটিতে কী স্বাদ এবং সম্মেলনের বিষয়। কোকো / কোকো টাচে, বর্তমান নির্বাচন এবং এমনকী ব্যবহারকারীর পছন্দগুলি নিয়ন্ত্রণকারীর মধ্যে রাখা সাধারণ বিষয়। কিছু ওয়েব ফ্রেমওয়ার্কগুলিতে ব্যবহৃত এমভিসি মডেলটির প্রায় সব কিছু এবং নিয়ামকটিতে খুব কম রাখে। YMMV।

— কালেব

4

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

— এরিক পুনরায়

1

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

— জানু হুডেক

4

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

— জোনাথন ওয়েদারহেড
সূত্র

2

নিয়ামক কোনও মডেলের আচরণের প্রতিনিধিত্ব করেন না। কন্ট্রোলাররা পুরো অ্যাপ্লিকেশনটির আচরণের প্রতিনিধিত্ব করে _ কোনও ব্যবহারকারী কী করতে পারে এবং ব্যবহারকারী কী দেখতে পারে।

নিয়ামক এবং মডেলগুলিকে এক হিসাবে দেখা ভুল। তাদের বিভিন্ন উদ্দেশ্য, বিভিন্ন শব্দার্থবিজ্ঞান রয়েছে এবং সুতরাং এক বস্তুতে একীকরণ করা উচিত নয়।

— superM
সূত্র

2

নিয়ন্ত্রণকারী স্তরটি কেবল যুক্তিযুক্ত হওয়ার চেয়ে মডেল স্তরটি কেবল ডেটা নয়।

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

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

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

— মাইকেল কে
সূত্র

2

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

এমভিসিতে একটি টুকরো ডেটা প্রদর্শন করার কার্যকারিতা (ভিউ) ডেটা (মডেল) থেকে আলাদা রাখা হয়। কেন এমন? এটি নির্দিষ্ট করে যাতে অন্তর্নিহিত ডেটা পরিবর্তন না করেই প্রদর্শন যুক্তি পরিবর্তন করা যায়। যখনই আপনাকে একই উপাত্তের আলাদা উপস্থাপনা করার প্রয়োজন হয় তখন ভিউটি পরিবর্তন করা সহজ করে তোলে: বা যখন ডিসপ্লে হার্ডওয়্যারটির বৈশিষ্ট্যগুলি পরিবর্তন হয়: বা আপনি যখন উইন্ডোজ থেকে লিনাক্সে স্যুইচ করেন; অথবা আপনি যখন চান দু'জনের একই ডেটা দেখার দুটি ভিন্ন উপায় থাকে।

এমভিসি ওওপির সাথে বিরোধে নয় - এটি আসলে অবজেক্ট ওরিয়েন্টেড নীতিগুলির সঠিক প্রয়োগ থেকে প্রাপ্ত der

— DJClayworth
সূত্র

0

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

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

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

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

— এরিক রেপেন
সূত্র

0

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

উদাহরণস্বরূপ, ওওপি / ওওডির পুরো পয়েন্টটি হল আপনার কোডটিকে আরও মডিউলার এবং পুনরায় ব্যবহারযোগ্য করে তোলা। হ্যাঁ?

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

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

— djm
সূত্র

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

— এরিক পুনরায়

-1

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

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

(এবং সম্ভবত আমি কিছুটা নিচে ভোট পেয়ে যাব?)

— aserwin
সূত্র

-1

বিরোধী নয়, তবে এমভিসির জন্যও ওওপি প্রয়োজন হয় না।

কারণ নিয়ামকগুলি, যা সাধারণত সংঘর্ষ দ্বারা প্রতিনিধিত্ব করা হয় কোনও ডেটা রাখে না। যার জন্য খাঁটি ফাংশন যথেষ্ট হবে।

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

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

— luke1985
সূত্র

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

— luke1985

নিশ্চিত নয় কেন এই উত্তরটির ডাউনটি রয়েছে। তিনি বলছেন যে এগুলি সম্পর্কিত নয়, "বিরোধী" নয়। বেশ নিখুঁত মনে হচ্ছে।

— mwilcox

-3

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

— user123790
সূত্র

এটি কি কেবল আপনার মতামত বা আপনি কোনওভাবে এটি ব্যাক আপ করতে পারেন?

— gnat