CodeGym/Java Course/মডিউল 3/MVC পদ্ধতি

MVC পদ্ধতি

বিদ্যমান

MVC আর্কিটেকচারের পরিচিতি

সর্বাধিক জনপ্রিয় অ্যাপ্লিকেশন আর্কিটেকচার যা প্রতিটি প্রোগ্রামার জানেন তা হল MVC । MVC মানে মডেল-ভিউ-কন্ট্রোলার

এটি অ্যাপ্লিকেশন উপাদানগুলির আর্কিটেকচারের মতো অ্যাপ্লিকেশনগুলির আর্কিটেকচার নয়, তবে আমরা পরে এই সংক্ষিপ্ততায় ফিরে যাব। MVC কি?

MVC হল তিনটি পৃথক উপাদান- মডেল, ভিউ এবং কন্ট্রোলার - এ অ্যাপ্লিকেশন ডেটা এবং কন্ট্রোল লজিককে আলাদা করার একটি স্কিম যাতে প্রতিটি উপাদান স্বাধীনভাবে পরিবর্তন করা যায়।

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

এই মডেলটি 1978 সালে (!) বছরে উদ্ভাবিত হয়েছিল। হ্যাঁ, সঠিক সফ্টওয়্যার আর্কিটেকচারের সমস্যা 50 বছর আগে প্রাসঙ্গিক ছিল। এখানে এই মডেলটিকে মূল চিত্রের মাধ্যমে কীভাবে বর্ণনা করা হয়েছে:

MVC আর্কিটেকচারের পরিচিতি

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

মডেলটি এমনভাবে তৈরি করা হয়েছে যাতে তার অবস্থা পরিবর্তন করে অনুরোধের প্রতিক্রিয়া জানানো যায় এবং "পর্যবেক্ষকদের" বিজ্ঞপ্তি তৈরি করা যেতে পারে। মডেল, চাক্ষুষ উপস্থাপনা থেকে স্বাধীনতার কারণে, একটি "মডেল" এর জন্য বিভিন্ন উপস্থাপনা থাকতে পারে ।

মডেল থেকে প্রয়োজনীয় ডেটা পাওয়ার এবং ব্যবহারকারীর কাছে পাঠানোর জন্য ভিউ দায়ী। ভিউ ব্যবহারকারীর ইনপুট প্রক্রিয়া করে না।

নিয়ামক ব্যবহারকারী এবং সিস্টেমের মধ্যে "যোগাযোগ" প্রদান করে। ব্যবহারকারীর কাছ থেকে সিস্টেমে ডেটা নিয়ন্ত্রণ এবং নির্দেশ করে এবং এর বিপরীতে। পছন্দসই কর্ম বাস্তবায়নের জন্য একটি মডেল এবং একটি দৃশ্য ব্যবহার করে।

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

ওয়েবে MVC আর্কিটেকচার

এমভিসি ডিজাইন প্যাটার্নের পিছনে ধারণাটি খুবই সহজ: আমাদের অ্যাপ্লিকেশনগুলিতে বিভিন্ন আচরণের জন্য আমাদের স্পষ্টভাবে দায়িত্ব আলাদা করতে হবে:

মডেল- ডেটা প্রসেসিং এবং অ্যাপ্লিকেশন লজিক।

দেখুন— ব্যবহারকারীকে যেকোনো সমর্থিত বিন্যাসে ডেটা প্রদান করা।

নিয়ন্ত্রক- ব্যবহারকারীর অনুরোধ প্রক্রিয়াকরণ এবং উপযুক্ত সংস্থান কল করা।

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

নিয়ন্ত্রক

ব্যবহারকারী ব্রাউজারে পৃষ্ঠার বিভিন্ন উপাদানগুলিতে ক্লিক করে, যার ফলস্বরূপ ব্রাউজারটি বিভিন্ন HTTP অনুরোধ পাঠায়: GET, POST বা অন্যান্য। নিয়ামক ব্রাউজার এবং জেএস কোড অন্তর্ভুক্ত করতে পারে যা পৃষ্ঠার ভিতরে কাজ করে।

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

মডেল

একটি বিস্তৃত অর্থে মডেল হল ডেটা এবং নিয়ম যা ডেটার সাথে কাজ করতে ব্যবহৃত হয় - একসাথে তারা অ্যাপ্লিকেশনটির ব্যবসায়িক যুক্তি তৈরি করে। একটি অ্যাপ্লিকেশান ডিজাইন করা সর্বদা এটি কাজ করে এমন বস্তুর মডেল তৈরির মাধ্যমে শুরু হয়।

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

আরও নিয়মের সেট রয়েছে: কী করা যায়, কী করা যায় না, কোন ডেটা সেট গ্রহণযোগ্য এবং কোনটি নয়। লেখক ছাড়া কি বই থাকতে পারে? আর বই ছাড়া লেখক? ব্যবহারকারীর জন্মতারিখ কি 300 সালের মধ্যে হতে পারে ইত্যাদি।

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

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

দেখুন

ভিউ মডেল থেকে প্রাপ্ত ডেটা উপস্থাপন করার বিভিন্ন উপায় প্রদান করে। এটি একটি টেমপ্লেট হতে পারে যা ডেটা দিয়ে পূর্ণ। বিভিন্ন মতামত থাকতে পারে এবং নিয়ামক বর্তমান পরিস্থিতির জন্য কোনটি সেরা তা বেছে নেয়।

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

ওয়েবে MVC উদাহরণ

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

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

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

আসুন দেখি কি হয় যদি একজন ব্যবহারকারী বইয়ের দোকানে প্রস্তাবিত বইয়ের তালিকা খোলে শিরোনাম দেখার জন্য। কর্মের পুরো ক্রমটি 6টি ধাপের আকারে বর্ণনা করা যেতে পারে:

ওয়েবে MVC উদাহরণ

ধাপ:

  1. ব্যবহারকারী "প্রস্তাবিত" লিঙ্কে ক্লিক করে এবং ব্রাউজারটি /books/recommendations-এ একটি অনুরোধ পাঠায়।
  2. নিয়ামক অনুরোধটি পরীক্ষা করে : ব্যবহারকারীকে অবশ্যই লগ ইন করতে হবে। অথবা আমাদের নন-লগ ইন ব্যবহারকারীদের জন্য বইয়ের সংগ্রহ থাকা উচিত। নিয়ামক তারপর মডেলটিকে কল করে এবং ব্যবহারকারী N কে সুপারিশকৃত বইগুলির তালিকা ফেরত দিতে বলে।
  3. মডেলটি ডাটাবেস অ্যাক্সেস করে, সেখান থেকে বই সম্পর্কে তথ্য পুনরুদ্ধার করে: বর্তমানে জনপ্রিয় বই, ব্যবহারকারীর কেনা বই, তার বন্ধুদের কেনা বই, তার পছন্দের তালিকা থেকে বই। এই ডেটার উপর ভিত্তি করে, মডেলটি প্রস্তাবিত 10টি বইয়ের একটি তালিকা তৈরি করে এবং সেগুলি নিয়ামকের কাছে ফেরত দেয়।
  4. নিয়ন্ত্রক সুপারিশকৃত বইয়ের একটি তালিকা পান এবং এটি দেখেন। এই পর্যায়ে, নিয়ামক সিদ্ধান্ত নেয়! যদি কিছু বই থাকে বা তালিকাটি সম্পূর্ণ খালি থাকে, তাহলে এটি একটি আনলগ করা ব্যবহারকারীর জন্য বইয়ের তালিকার অনুরোধ করে। যদি এখনই কোনো প্রচার চলছে, তাহলে নিয়ন্ত্রক তালিকায় প্রচারমূলক বই যোগ করতে পারেন।
  5. ব্যবহারকারীকে কোন পৃষ্ঠাটি দেখাতে হবে তা নিয়ামক নির্ধারণ করে। এটি একটি ত্রুটির পৃষ্ঠা হতে পারে, বইয়ের একটি তালিকা সহ একটি পৃষ্ঠা, একটি পৃষ্ঠা অভিনন্দন যে ব্যবহারকারী এক মিলিয়ন দর্শক হয়ে উঠেছে।
  6. সার্ভার ক্লায়েন্টকে কন্ট্রোলার দ্বারা নির্বাচিত পৃষ্ঠা ( দর্শন ) দেয়। এটি প্রয়োজনীয় ডেটা (ব্যবহারকারীর নাম, বইয়ের তালিকা) দিয়ে ভরা হয় এবং ক্লায়েন্টের কাছে যায়।
  7. ক্লায়েন্ট পৃষ্ঠাটি গ্রহণ করে এবং ব্যবহারকারীর কাছে এটি প্রদর্শন করে।

এই পদ্ধতির সুবিধা কি?

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

দ্বিতীয় সুবিধা হল সার্ভারের অংশটিকে দুটি ভাগে ভাগ করা: একটি স্মার্ট মডেল ( নির্বাহক ) এবং একটি নিয়ামক ( সিদ্ধান্ত কেন্দ্র )।

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

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

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

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

MVC-এর ধারণাটি বোঝার পরে, আপনি, একজন বিকাশকারী হিসাবে, বুঝতে পারেন যে বইগুলির তালিকা বাছাই করার জন্য আপনাকে কোথায় যোগ করতে হবে:

  • ডাটাবেস ক্যোয়ারী স্তরে.
  • ব্যবসায়িক যুক্তির স্তরে (মডেল)।
  • ব্যবসায়িক যুক্তি স্তরে (নিয়ন্ত্রক)।
  • দৃশ্যে - ক্লায়েন্টের দিকে।

এবং এটি একটি অলঙ্কৃত প্রশ্ন নয়. এখনই, বইয়ের তালিকা সাজানোর জন্য আপনাকে কোথায় এবং কেন কোড যোগ করতে হবে তা নিয়ে ভাবুন।

ক্লাসিক MVC মডেল

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

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

বিভিন্ন মডেলের উপাদানগুলির মিথস্ক্রিয়া এইরকম দেখায়:

ক্লাসিক MVC মডেল

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

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

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

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

বর্তমানে, এই সমস্যাটি আংশিকভাবে নিম্নলিখিত পদ্ধতিগুলি ব্যবহার করে সমাধান করা হয়েছে:

  • গুরুত্বপূর্ণ ডেটাতে পরিবর্তনের জন্য সার্ভারে নিয়মিত পোলিং করুন (এক মিনিট বা তার বেশি একবার)।
  • WebSockets একটি ক্লায়েন্ট সার্ভার বার্তা সাবস্ক্রাইব করার অনুমতি দেয়.
  • সার্ভারের দিক থেকে ওয়েব পুশ বিজ্ঞপ্তি।
  • HTTP/2 প্রোটোকল সার্ভারকে ক্লায়েন্টকে বার্তা পাঠানো শুরু করতে দেয়।
মন্তব্য
  • জনপ্রিয়
  • নতুন
  • পুরানো
মন্তব্য লেখার জন্য তোমাকে অবশ্যই সাইন ইন করতে হবে
এই পাতায় এখনও কোনো মন্তব্য নেই