এমভিসিতে একটি নিয়ামক শ্রেণিতে ব্যক্তিগত, অ-অ্যাকশন, ফাংশনগুলি রাখা ভাল অনুশীলন হিসাবে বিবেচিত হয়?


10

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

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

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

উত্তর:


16

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

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

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


সৃজনশীল উপমা জন্য +1। :) আপনি একটি আকর্ষণীয় পয়েন্ট করা। বিশেষত খারাপ অভ্যাস গঠনের বিষয়ে। ধন্যবাদ.
ডেভিড 'টাক আদা'

8

আমি যে সর্বোত্তম উত্তর দিতে পারি তা হল রবার্ট মার্টিনের "ক্লিন কোড" এর দুর্দান্ত বইয়ের উদ্ধৃতি দেওয়া, যা আমি এই বিষয়ে আগ্রহী যে কাউকে অত্যন্ত পরামর্শ দিচ্ছি:

ফাংশনগুলির প্রথম নিয়মটি হ'ল সেগুলি ছোট হওয়া উচিত। দ্বিতীয় নিয়মটি হ'ল তাদের চেয়ে ছোট হওয়া উচিত।

এর চেয়ে ভাল বলতে পারছি না। একই বইয়ের আর একটি দুর্দান্ত উদ্ধৃতি প্রযোজ্য:

কার্য একটি কাজ করা উচিত। তাদের এটি ভালভাবে করা উচিত। তাদের কেবল এটি করা উচিত।

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

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


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

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

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

0

এমভিসি-তে আমি চেষ্টা করে দেখি যে আমার নিয়ামক যতটা সম্ভব "পাতলা" এবং আমার মডেলগুলি যতটা সম্ভব বোবা।

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

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

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

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


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

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

আমার অনুভূতি আছে যে এই উত্তরটির অর্থ ভাল তবে এটি ভুলভাবে বলা হয়েছে .. বা, সম্ভবত ভিন্ন ভিন্ন পরিভাষা।
সাইমন হোয়াইটহেড

3
"সহায়ক" শ্রেণিগুলি কোনও স্থাপত্য উপাদান নয়। তারা এম, ভি, অথবা সি উভয় অংশ আপনি কি নিশ্চিতরূপে যা, তবে তাদেরকে সাহায্যকারী অভাব না হন, তাহলে সংযোগ । "হেল্পার" শব্দটি "হ্যান্ডেল", "কর", "সঞ্চালন" এবং ভয়ঙ্কর ব্যবস্থাপকের সাথে ঠিক সেখানে রয়েছে
অ্যারোনআউট

@ সিমন হোয়াইটহেড: বেশিরভাগ উত্তরগুলির অর্থ ভাল তবে অনেকগুলি সঠিক নয়। দুর্ভাগ্যক্রমে, এটি হয় "মডেল" এর অর্থের একটি ভুল বোঝাবুঝির প্রচার করে বা এর বাইরে সমালোচনামূলক ব্যবসায় যুক্তি যুক্ত করার পরামর্শ দিচ্ছে। আমি এক মিলিয়ন "সহায়তাকারী" দিয়ে এমভিসি সাইটগুলি বজায় রাখার সন্দেহজনক আনন্দ পেয়েছি - তারা ভয়ঙ্কর।
অ্যারোনআট

-2

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

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

KISS নীতিটি সর্বদা মনে রাখবেন: এটিকে সহজ, বোকা রাখুন।


5
যে না বেসরকারী পদ্ধতি এড়ানো জন্য একটি ভাল কারণ MVC স্থাপত্য সাথে কিছু নেই, এবং এছাড়াও। আপনি ব্যক্তিগত পদ্ধতি পরীক্ষা করার চেষ্টা করবেন না , সেগুলি সর্বজনীন পদ্ধতিতে পরীক্ষাগুলির দ্বারা আচ্ছাদিত করা উচিত । যদি আপনি এগুলি আবরণ করতে না পারেন, তবে এটি এমন একটি চিহ্ন যা আপনার ক্লাসটি খুব জটিল এবং পুনরায় সঞ্চারিত হওয়া দরকার; এর অর্থ এই নয় যে আপনার ব্যক্তিগত পদ্ধতি না থাকা উচিত বা (আমি আন্তরিকভাবে আশা করি এটি আপনি যা বোঝাতে চেয়েছিলেন তা সত্য নয়) পরিবর্তে সেগুলি সর্বজনীন হওয়া উচিত।
অ্যারোনআট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.