এমভিসির পতনগুলি কী কী? [বন্ধ]

Question

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

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

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

Comments

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

— gnat

এমভিসি আর্কিটেকচারটি কেবল সমস্যাগুলির সেটগুলিতে প্রযোজ্য বলে আপনার প্রশ্নের উত্তর দেওয়ার আগে আমার এমভিসি সম্পর্কে আপনার সংজ্ঞা কী, তার একটি উত্তর আমার প্রয়োজন হবে। সুতরাং আপনি যদি এটি ভুল জায়গায় ব্যবহার করেন তবে আপনার পতন হবে।

— বেন ম্যাকডুগাল

আপনার বিভিন্ন কাজের মধ্যে কত বৈচিত্র্য আছে?

— JeffO

'এমভিসি অবজেক্ট ওরিয়েন্টেড নয়' এর একটি পাঠ্য পড়ুন ।

— mcintyre321

@ জেফো পিএইচপি অ্যাপস (ব্যাকএন্ড, জেএস নয় এমন ভারী সাইটগুলি), ফ্রন্ট-এন্ড অ্যাপ্লিকেশনগুলি। সুতরাং, সমস্ত ওয়েব, কিন্তু ফ্রন্ট-এন্ড এবং ব্যাকএন্ড।

— অস্কার গডসন

Answer 1

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

এটা আমার বৃহত্তম ভুল ছিল। এই সহজ নিয়মটি বুঝতে পেরে আমি দীর্ঘ সময় ব্যয় করেছি:

• পুরো প্রয়োগের মধ্যে একটি এমভিসি প্যাটার্ন ছড়িয়ে দেবেন না,
• এটি কেবলমাত্র UI- সম্পর্কিত স্টাফের মধ্যে সীমাবদ্ধ করুন।

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

আপনি যে সমস্ত নিদর্শনগুলিকে এমভিসি-বিকল্পগুলি (যেমন মডেল-ভিউ-উপস্থাপক, মডেল-ভিউ-ভিউমোডেল) বলেছেন সেগুলি সাধারণ এমভিসি ধারণাটি বাস্তবায়নের একমাত্র উপায়।

Comments

আসলে আপনি যে কোনও সময় বিমূর্ত স্তর থাকলে এমভিসি বাস্তবায়ন করতে পারেন; এপিআই হ'ল ভিউ / কন্ট্রোলার এবং অন্তর্নিহিত যুক্তি হ'ল মডেল

— রাচেট ফ্রিক

@ratchetfreak, টেকনিক্যালি একটি API ভাষী হয় UI 'তে, যেখানে ব্যবহারকারী API ব্যবহার করে প্রোগ্রামার একটি ফর্ম।

— zzzzBov

@ratchetfreak: এটি কি ফ্যাডে প্যাটার্ন হিসাবে শ্রেণিবদ্ধ করা হবে না?

— জেরোইন ভেনেভেল

এমভিসি ইউআই-তে সবচেয়ে বেশি কার্যকর হতে পারে তবে উদ্বেগের বিষয়টি আলাদা করা কেবলমাত্র সেখানেই কার্যকর is

— ডগএম

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

— জাভিয়ের

Answer 2

আমার মতে দুটি প্রকারের এমভিসি রয়েছে - খাঁটি এবং নাপাক (আরও ভাল শব্দের অভাবে :)

খাঁটি এমভিসি হ'ল ছোট্ট আলোচনায়:

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

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

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

এখন, এখানে কীভাবে একটি ওয়েব অ্যাপ্লিকেশনটি সাধারণত কাঠামোযুক্ত হয়:

1. ফ্রন্ট-এন্ড : ক্লায়েন্টের এমভিসি ফ্রেমওয়ার্কগুলি ব্যাকবোন.জেএস ইত্যাদি হিসাবে ব্যবহার করে, মূলত এটি 'সত্য' এমভিসি ফর্ম।
2. ব্যাক-এন্ড : আবার কোড সংস্থার এবং উদ্বেগের পৃথকীকরণের জন্য আপনার কাছে (অপবিত্র) এমভিসি / পিএসি রয়েছে AC
3. গ্লোবাল ওয়েব অ্যাপ্লিকেশন (সামগ্রিকভাবে ওয়েব অ্যাপ্লিকেশনের জন্য): যদি আপনার কাছে RESTful ব্যাকএন্ড থাকে যা কেবল JSON ডেটা দেয়, তবে আপনার সম্পূর্ণ ব্যাকএন্ডটি ফ্রন্ট-এন্ড ক্লায়েন্ট অ্যাপ্লিকেশনের একটি মডেল হিসাবে উপলব্ধি করা যেতে পারে যেখানে ভিউ এবং কন্ট্রোলার মূলত থাকে।

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

আপনি এটি সর্বত্র ব্যবহার করা উচিত? হয়তো না. অত্যন্ত জটিল ওয়েব অ্যাপ্লিকেশনগুলি একাধিক স্তরে বিভক্ত হতে পারে! আপনি কেবল ভিউ / বিজনেস লজিক / ডেটা স্তরগুলি দিয়ে পালাতে পারবেন না। ওভারারচিং ফ্রেমওয়ার্ক / সংগঠনটি এখনও এমভিসি-ইশ হতে পারে তবে কেবল ম্যাক্রোস্কোপিক স্তরে।

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

Comments

"খাঁটি বনাম অপরিষ্কার" এর জন্য +1। যদিও আমি "জিইউআই বনাম ওয়েব এমভিসিগুলি" ব্যবহার করতে পছন্দ করি এবং এটি নির্দেশ করে যে ওয়েব এমভিসি স্তরযুক্ত অবস্থায় জিইউআই এমভিসি মডুলার । আমি সত্যই কামনা করি যে ওয়েব এমভিসিটিকে অন্য কিছু বলা হয়েছিল, যেহেতু এটি "খাঁটি এমভিসি" থেকে খুব আলাদা, তবে মনে হয় এটির জন্য খুব দেরি হয়ে গেছে।

— জাভিয়ের

আমি চিত্রটি পছন্দ করি। করছেন। শব্দটি, সম্ভবত "ট্র্যাডিশনাল এমভিসি বনাম প্রাপ্ত এমভিসি" :) :)

— এডউইন ইপ

Answer 3

নকশা নিদর্শনগুলির সাথে অনেক লোক ভুল করে দেখছে যে এটি এক জায়গায় সুন্দরভাবে কাজ করে এবং এরপরে সর্বত্র এটি প্রয়োগ করার চেষ্টা করছে।

আপনি যদি কিছু জায়গায় এক জায়গায় কাজ করে থাকেন, তখন প্রযুক্তি / নকশার ধরণগুলি / পদ্ধতিগুলি সেই সময়ে প্রচলিত ছিল যেমন: সিঙ্গলেটন / নির্ভরতা ইনজেকশন / টিডিডি ইত্যাদি ইত্যাদি দেখে আপনি প্রায় কোনও কোডের তারিখ করতে পারেন etc.

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

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

Comments

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

— ডগএম

কনসোল একটি ইউআই। কেবল পাঠ্য ভিত্তিক, সুতরাং আপনার অনুমানটি ভুল।

— গার্ডিয়ানএক্স

@ গুয়ার্ডিয়ানএক্স আমি এই শব্দটিকে মোটেও খুব একটা ভালভাবে বলতে পারি নি। আমি পরিষ্কার করতে আমার উত্তর সম্পাদনা করেছি।

— রবি ডি

Answer 4

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

প্রথম সমস্যার বিকল্প হ'ল এই জাতীয় কোডকে স্বতন্ত্র উপ-প্রকল্পগুলিতে আলাদা করা; দ্বিতীয়টির বিকল্পটি ক্লাসে বা ফাইলের মডেলটিতে, অ-বিচ্ছিন্ন কোড।

Comments

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

— রবি ডি

@ রবি: আহ! বৈশিষ্ট্য বিন্দু!

— ডগএম

Answer 5

এমভিসি / এমভি * প্রয়োগের বিষয়ে আমার উপলব্ধি কনসার্নস বিচ্ছিন্নকরণ (এসওসি) নীতি অনুসরণ করছে - প্রোগ্রাম / কোডগুলিকে পৃথক বিভাগ / টুকরোতে পৃথক করে যাতে প্রতিটি বিভাগ পৃথক উদ্বেগকে মোকাবেলা করতে পারে (রেফার: http://en.wikedia.org / উইকি / পৃথকীকরণের_কেন্দ্রিক )

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

আপনি যখন ইউআই সম্পর্কিত বিকাশ পরিচালনা করছেন তখন এমভিসি / এমভি * খুব কার্যকর, যখন নীচে আরও নিদর্শনগুলি থাকতে পারে - কারখানা, সিঙ্গলটন, ফ্যাসাদ এবং ইত্যাদি projects কিছু কারন. আপনি এমভিসিটিকে অনেকগুলি দেখতে পাচ্ছেন - এটি কারণ অনেকগুলি প্রকল্পে ইউআই উপাদান রয়েছে।

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

সুতরাং এমভিসি (বা আরও সাধারণ - একটি নকশার ধরণ) মূল্যায়ন করার জন্য, এটিকে একটি প্রসঙ্গ দিন এবং জটিলতা, স্কেলাবিলিটি, টেস্টাব্ল্যাটি, রক্ষণাবেক্ষণ, সময়ের সীমাবদ্ধতা ইত্যাদি ইত্যাদি সম্পর্কে ভাবেন