সফটওয়্যার আর্কিটেকচার: মডেল-ভিউ-কন্ট্রোলার (MVC)

মডেল-ভিউ-কন্ট্রোলার(MVC) একটি পরিচিত সফটওয়্যার আর্কিটেকচার। সফটওয়্যার/ওয়েব অ্যাপ ডেভেলপমেন্টে (MVC) আর্কিটেকচার ব্যবহার করে অনেক সুবিধা পাওয়া সম্ভব।

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

ভিউ: এ অংশের কোডে থাকবে শুধুমাত্র ইউজার ইন্টারফেসের কোড,অন্য কোনো কিছু না। যেমন: ওয়েব ডেভেলপিং এর ক্ষেত্রে MVC আর্কিটেকচারের ভিউ অংশে থাকবে শুধুমাত্র HTML/XHTML কোড, ফ্ল্যাশ অ্যানিমেশন । অবশ্যই একটি মডেলের জন্য একাধিক ভিউ ফাইল থাকতে পারে কিন্তু লজিকাল কোনো ব্যাপার ভিউতে থাকবেনা।

মডেল: এ অংশে থাকবে আপনার সমস্ত ফাংশন,ডাটাবেস কুয়েরি ইত্যাদি। এখানে ডিসপ্লের কোনো প্রকার কাজ হবেনা,আপনাকে কিছু ভ্যারিয়েবল প্যারামিটার হিসাবে পাঠানো হতে পারে,নাও পারে,আপনি ফাংশনে আপনার প্রয়োজনীয় কাজ করে কনট্রোলারকে রিটার্ন করবেন। মডেল যে ডাটা রিটার্ণ করে সেগুলো “display-neutral”, অর্থাত কোনো ডিসপ্লে ফরমেটিং থাকেনা সেগুলোতো।

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

mvc,shafaetsblog

তাহলে ইউজার যা দেখছে সেটা ভিউ,ইউজারের ইনপুট গ্রহণ করছে কন্ট্রোলার,সে ইনপুট মডেলে পাঠিয়ে প্রসেস করছে,পরে প্রসেস করা ডাটা আবার ভিউতে পাঠিয়ে ইউজারকে প্রদর্শন করছে।

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

কন্ট্রোলারের কনসেপ্টটাও গুরুত্বপূর্ণ। অ্যাপ্লিকেশনের কন্ট্রোলার যার হাতে থাকবে সে একাধিক মডেল বা ভিউ হতে ইচ্ছামত নির্বাচন করতে পারবে। ধরো তুমি তোমার সাইটের ডিজাইন টেমপ্লেট পাল্টাতে চাও,তোমার HTML/XHTML আর PHP/ASP/Python কোড একসাথে থাকলে কি ঘটবে? তোমাকে নতুন টেম্প্লেটের ভিতর আবার ফাংশন গুলো বসাতে হবে যা অনেক সময়সাপেক্ষ। কিন্তু MVC তে তুমি খালি ভিউ ফাইলটা বদলে দিবে,কাজ শেষ।

একটা MVC অ্যাপ্লিকেশনে অনেকগুলো মডেল-ভিউ-কন্ট্রোলারের সমষ্টিও হতে পারে। জাভার সুইং লাইব্রেরির প্রতিটা কম্পোনেন্ট আলাদা MVC ব্যবহার করে।

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

MVC কিভাবে ব্যাবহার করবে? ১টি উপায় হলো নিজেই MVC আর্কিটেকচারের মূলনীতিগুলো মেনে কোডিং করা। আরো সহজ উপায় হলো ফ্রেমওয়ার্ক ব্যবহার করে। ওয়েবে খুব জনপ্রিয় একটি পিএইচপি ফ্রেমওয়ার্ক হলো কোডইগনাইটার। ফ্রেমওয়ার্ক তোমাকে মডেল-ভিউ-কন্ট্রোলার সবগুলোর জন্য আলাদা ফ্রেম তৈরি করে দিবে,তুমি শুধু ফ্রেমগুলোতে কোড লিখবে। এছাড়া বেশীভাগ ফ্রেমওয়ার্ক আরো কিছু সুবিধা দেয়। যেমন ডাটাবেসে সহজে কুয়েরির জন্য কিছু লাইব্রেরি। পাইথনের django সহ অন্যান্য কিছু ফ্রেমওয়ার্কে এমন লাইব্রেরি আছে যা স্বয়ংক্রিয় ভাবে HTML কোড জেনারেট করবে,আপনাকে খালি পাইথনের সিনট্যাক্সে কোড লিখতে হবে। জাভা,সি++ সবকিছুর জন্যই MVC ফ্রেমওয়ার্ক পাওয়া যায়। চাইলে নিজেরই একটা ফ্রেমওয়ার্ক বানিয়ে নিতে পারো :)।

রেফারেন্স:
http://www.techrepublic.com/article/mvc-design-pattern-brings-about-better-organization-and-code-reuse/1049862

http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

Print Friendly

ফেসবুকে মন্তব্য

comments

Powered by Facebook Comments

7 thoughts on “সফটওয়্যার আর্কিটেকচার: মডেল-ভিউ-কন্ট্রোলার (MVC)

  1. Good work.But let me notify the actual mistake in your concept.The image you have shown is not right.Model cant directly pass datas to view(no interconnection),but you showed an arrow from model to view.And model never process any data it just stores them,its the controller which takes the data from model,processes it and shows it on your view.But in controller part you said model processes data.This model is also described as:View(Presentation layer),Controller(Logic/Business layer),Model(Data layer).So all processing logic goes inside of controller.”চাইলে মডেলকেও কয়েক ভাগে ভাগ করে নেয়া যায়,এক অংশে হয়তো থাকবে অ্যালগোরিদম,আরেক অংশে ডাটাবেস,ফলে কাজে আরও সুবিধা হবে।”-The actual MVC pattern doesn’t tell anything like this,there can’t be any algo inside of model.Please learn the basics perfectly before you approach to let it learn.And also please make your blog readable for everyone.There’s a little chance that each visitor is junior than you and seniors would not wish to learn from your blog.So please remove the তুমি format! 🙂 None of these are anything that meant to hurt you.Thanks for your great initiative.Keep it up. 😀

  2. Thanks a lot for your comment,i greatly appreciate criticisms,we all learn from mistakes.

    I’ve taken the pic from another site. After reading your comments i’ve google more and found arrow from model to view in almost every pic including wiki. According to wiki model–>view association is indirect via an observer.

    Now see whats written in developer.apple.com:

    “”Model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. “”

    and also:
    “Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. ”

    So as far as i understand model contain some methods that process the data,controller just get data from model and send it to view. Where am i wrong? Please give me some reference.

    Sorry if “তুমি format” offended you,i greatly respect my seniors for sure.

  3. http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1

    এখানে লিখেছে:
    “”The controller does not display the data in the model, it only triggers methods in the model which modify the data, and then pass the model into the view which displays the data.””

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

    (ছবিটা পাল্টে দিয়েছি,এখনকার ছবিটা বেশি পরিষ্কার)

  4. As far I am aware Model and Controller can be defined in multiple ways based on the logic you are planning to manipulate. You could probably choose a Fat Model and a Thin Controller or a Thin Model and Fat Controller.

    A Fat model means you are allowing the model to manipulate more instructions on processing (Not only storing data) while using a less control instructions for controller (Lets say simply letting it to perform the communications while required only). On the other hand Thin Model and Fat Controller would do the opposite. When you put your more power in controller, you actually make your controller bulky and heavy to operate. Controller is the least re-usable part of MVC (In theory). I have no idea why would someone use a Framework if anyone planning to use a Thin Model and Fat Controller as the primary objective is just the opposite of it’s advantage. If I have to make another controller to make my framework reusable (Fat Controller Architecture), it probably worth nothing to me.

    On the other hand, A Fat Model provides more control over your data, manipulation and re-usability while letting the Controller performing least tasks for you.

    I have never seen anyone defining MVC, strictly as Thin Model & Fat Controller architecture like Mr. Dibosh has said. Good luck Shafaet.

  5. Well,discussions always help us to learn in a right way 🙂 Please take a look at the stanford lecture given here: http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259
    I learned MVC primarily from there videos and lectures and tried to incorporate it with my ASP.NET developments.Well things need to be clarified,to me what I meant was databases or data sources are perfectly meant to be models.Yes if we think of a class that handles all the data specific operation as Model,I must say you are right.But I extracted that class from Model and added it to Controller as it also does the same,some logic needed to manipulate data perfectly.Let me explain what I said a bit clearly.
    View:User interaction/UX
    Controller: all logic goes here
    Model:only the data providers(e.g.database,a stack/queue)
    I didn’t mean Model to have the class to access it should have been associated with it rather encapsulated that inside of controller.
    That’s why the confusion arises.And after all these discussions I learned what you meant to say and must say yes this is the right way of course 🙂
    And just to add Mr.Rondhro,this is the more specific way that we follow in our office,this is nothing like so called Fat/thin,rather we consider the class responsible for Model also to be included in Controller bundle.And believe me it’s the most followed practical approach. By the way thanks for your clarification.
    And Shafayet bro,keep these discussions up,this will certainly help us to become matured in tech-life.Good luck.

Leave a Reply

Your email address will not be published. Required fields are marked *


Time limit is exhausted. Please reload CAPTCHA.