এমভিসি ডিজাইন প্যাটার্নের প্রধান হিসাবে রেলগুলি দেখার পক্ষে সেরা ধারণা নাও হতে পারে। বলেছিল কাঠামোটি কিছু সহজাত ত্রুটিগুলি নিয়ে তৈরি হয়েছিল (আমি এটি একটি ভিন্ন পোস্টে ব্যাখ্যা করেছি ) এবং সম্প্রদায়টি এখনই ফলস্বরূপকে সমাধান করতে শুরু করেছে। আপনি প্রথম বড় পদক্ষেপ হিসাবে ডেটা ম্যাপার 2 বিকাশের দিকে নজর দিতে পারেন ।
কিছু তত্ত্ব
যে পরামর্শ দেওয়া লোকেরা মনে হয় এটি একটি সাধারণ প্রচলিত ভুল ধারণা দ্বারা আক্রান্ত হয়েছে। সুতরাং আমাকে এটি পরিষ্কার করে শুরু করা যাক: আধুনিক এমভিসি ডিজাইনের ধরণীতে মডেল কোনও শ্রেণি বা অবজেক্ট নয়। মডেল একটি স্তর।
এমভিসি প্যাটার্নের পেছনের মূল ধারণাটি কনসার্নসকে আলাদা করা এবং এর প্রথম পদক্ষেপটি উপস্থাপনা স্তর এবং মডেল স্তরগুলির মধ্যে বিভাজন। যেমন উপস্থাপনা স্তরটি কন্ট্রোলারগুলিতে বিভক্ত হয় (উদাহরণস্বরূপ, ব্যবহারকারী ইনপুট নিয়ে কাজ করার জন্য দায়বদ্ধ), দৃষ্টিভঙ্গি (উদাহরণগুলি, ইউআই যুক্তির জন্য দায়ী) এবং টেমপ্লেট / লেআউটগুলিও একইভাবে মডেল স্তরটিকে অন্তর্ভুক্ত করে।
মডেল স্তরটি যে প্রধান অংশগুলি নিয়ে গঠিত সেগুলি হ'ল:
ডোমেন অবজেক্টস
ডোমেন সত্তা, ব্যবসায়িক অবজেক্টস বা মডেল অবজেক্টস হিসাবেও পরিচিত (আমি সেই নামটি অপছন্দ করি কারণ এটি কেবল বিভ্রান্তি যুক্ত করে)। এই কাঠামোগুলি হ'ল লোকে সাধারণত ভুল করে "মডেল" বলে। তারা ব্যবসার বিধি (ডোমেন লজিকের নির্দিষ্ট ইউনিটের সমস্ত গণিত এবং বৈধতা) রাখার জন্য দায়বদ্ধ।
স্টোরেজ বিমূর্ততা:
সাধারণত ডেটা ম্যাপার প্যাটার্ন ব্যবহার করে প্রয়োগ করা হয় ( ওআরএমগুলির সাথে বিভ্রান্ত করবেন না , যা এই নামটি ব্যবহার করেছে)। এই দৃষ্টান্তগুলি সাধারণত তথ্য স্টোরেজ থেকে এবং ডোমেন অবজেক্টগুলিতে পুনরুদ্ধার করা হয়। প্রতিটি ডোমেন অবজেক্টের বিভিন্ন ম্যাপার থাকতে পারে, ঠিক তেমন স্টোরেজের বিভিন্ন ধরণের (ডিবি, ক্যাশে, সেশন, কুকিজ, / দেব / নাল) রয়েছে।
সেবা:
অ্যাপ্লিকেশন লজিকের জন্য দায়ী কাঠামো (এটি, ডোমেন অবজেক্টের মধ্যে মিথস্ক্রিয়া এবং ডোমেন অবজেক্ট এবং স্টোরেজ বিমূর্তনের মধ্যে মিথস্ক্রিয়া)। তাদের "ইন্টারফেস" এর মতো কাজ করা উচিত যার মাধ্যমে উপস্থাপনা স্তরটি মডেল স্তরের সাথে যোগাযোগ করে। এটি সাধারণত রেলের মতো কোড নিয়ন্ত্রকদের মধ্যেই শেষ হয়।
এই গোষ্ঠীগুলির মধ্যে ফাঁকা জায়গাগুলির মধ্যে বেশ কয়েকটি কাঠামো রয়েছে: ডিএও , কাজের ইউনিট এবং সংগ্রহশালা ।
ওহ ... এবং যখন আমরা এমভিসি অ্যাপ্লিকেশনটির সাথে ইন্টারঅ্যাক্ট করে এমন কোনও ব্যবহারকারী সম্পর্কে (ওয়েবের প্রসঙ্গে) কথা বলি , এটি কোনও মানুষ নয়। "ব্যবহারকারী" আসলে আপনার ওয়েব ব্রাউজার।
তাহলে দেবদেবীদের কী হবে?
কিছু ভীতিজনক ও একঘেয়ে মডেল নিয়ে কাজ করার পরিবর্তে, নিয়ন্ত্রকদের পরিষেবাগুলির সাথে যোগাযোগ করা উচিত। আপনি ব্যবহারকারীর ইনপুট থেকে একটি নির্দিষ্ট পরিষেবাদিতে ডেটা পাস করেন (উদাহরণস্বরূপ MailServiceবা RecognitionService)। এভাবে নিয়ন্ত্রক মডেল স্তরের অবস্থার পরিবর্তন করে তবে এটি একটি পরিষ্কার এপিআই ব্যবহার করে এবং অভ্যন্তরীণ কাঠামোগুলি নিয়ে ঝামেলা না করেই করা হয় (যা কোনও ফাঁসী বিমূর্তির কারণ হতে পারে)।
এই জাতীয় পরিবর্তনগুলি হয় কিছুটা তাত্ক্ষণিক প্রতিক্রিয়া সৃষ্টি করতে পারে বা ভিউ দৃষ্টান্তটি মডেল স্তর থেকে অনুরোধ করা ডেটা বা উভয়কেই প্রভাবিত করে।
প্রতিটি পরিষেবা ডোমেন অবজেক্ট এবং স্টোরেজ বিমূর্ততা যে কোনও সংখ্যক (যদিও এটি সাধারণত কেবলমাত্র কয়েক মুঠো) সাথে ইন্টারেক্ট করতে পারে। উদাহরণস্বরূপ, RecogitionServiceনিবন্ধগুলির জন্য স্টোরেজ বিমূর্তকরণ সম্পর্কে কম যত্ন নিতে পারে না।
নোট বন্ধ হচ্ছে
এইভাবে আপনি এমন একটি অ্যাপ্লিকেশন পাবেন যা কোনও স্তরে ইউনিট-টেস্ট করা যেতে পারে, কম সংযোজন রয়েছে (যদি সঠিকভাবে প্রয়োগ করা হয়) এবং পরিষ্কারভাবে বোধগম্য আর্কিটেকচার রয়েছে।
যদিও, মনে রাখবেন: এমভিসি ছোট অ্যাপ্লিকেশনগুলির জন্য নয়। আপনি যদি এমভিসি প্যাটার্ন ব্যবহার করে কোনও গেস্টবুক পৃষ্ঠা লিখছেন তবে আপনি এটি ভুল করছেন। এই প্যাটার্নটি বৃহত্তর অ্যাপ্লিকেশনগুলিতে আইন শৃঙ্খলা প্রয়োগের জন্য is
লোকেদের যারা পিএইচপি প্রাথমিক ভাষা হিসাবে ব্যবহার করছেন তাদের পক্ষে এই পোস্টটি প্রাসঙ্গিক হতে পারে। কোডের কয়েকটি স্নিপেট সহ এটি মডেল স্তরের কিছুটা দীর্ঘ বিবরণ।