MVC: Model-View-Controller প্যাটার্নের সারাংশ এবং এর বাস্তবায়ন

MVC কী: Model-View-Controller প্যাটার্নের সারাংশ

MVC (Model-View-Controller) একটি আর্কিটেকচারাল প্যাটার্ন যা Trygve Reenskaug 1979 সালে Smalltalk-80 ভাষার জন্য প্রস্তাব করেছিলেন। প্যাটার্নটি অ্যাপ্লিকেশনকে তিনটি স্তরে বিভক্ত করে: Model-এ ডেটা এবং বিজনেস লজিক থাকে, View প্রদর্শনের জন্য দায়ী, Controller ব্যবহারকারীর ইনপুট প্রক্রিয়া করে এবং Model ও View আপডেট করে। দায়িত্বের পৃথকীকরণ প্রতিটি স্তরকে স্বাধীনভাবে পরিবর্তন করার অনুমতি দেয় — উদাহরণস্বরূপ, Model-এ বিজনেস লজিক পরিবর্তন না করেই View-কে UIKit থেকে SwiftUI-তে পরিবর্তন করা।

উপাদান মিথস্ক্রিয়া MVC-তে একটি চক্র অনুসরণ করে: ব্যবহারকারী View-এর সাথে ইন্টারঅ্যাক্ট করে → Controller ইভেন্ট গ্রহণ করে → Controller Model আপডেট করে → Model Controller-কে পরিবর্তন সম্পর্কে জানায় → Controller View আপডেট করে। ক্লাসিক বাস্তবায়নে, Model Observer প্যাটার্ন ব্যবহার করে: ডেটা পরিবর্তিত হলে, Model বিজ্ঞপ্তি পাঠায়, Controller সাবস্ক্রাইব করে এবং View আপডেট করে। Apple-এর বাস্তবায়নে, Key-Value Observing (KVO) বা NotificationCenter এই ভূমিকা পালন করে।

আধুনিক মোবাইল ডেভেলপমেন্টে MVC 10 বছর আগের তুলনায় কম ব্যবহৃত হয়, কিন্তু এটি বোঝা অপরিহার্য। Apple UIKit অ্যাপ্লিকেশনে সাধারণ স্ক্রিনের জন্য MVC সুপারিশ করে। Google Android-এর জন্য বিশুদ্ধ MVC সুপারিশ করে না — অফিসিয়াল ডকুমেন্টেশন Jetpack-এর সাথে MVVM সুপারিশ করে। তবে, লিগ্যাসি প্রকল্পগুলির সাথে কাজ করার এবং আর্কিটেকচারাল প্যাটার্নের বিবর্তন বোঝার জন্য MVC-এর জ্ঞান প্রয়োজনীয়।

iOS-এ MVC: UIViewController এবং Storyboard

Apple MVC হল UIKit-এ নির্মিত প্যাটার্নের একটি কাস্টম বাস্তবায়ন। UIViewController Controller হিসেবে কাজ করে: স্ক্রিন লাইফসাইক পরিচালনা করে (viewDidLoad, viewWillAppear, viewDidDisappear), স্পর্শ এবং ব্যবহারকারীর ক্রিয়া পরিচালনা করে, IBOutlets-এর মাধ্যমে View আপডেট করে। View Interface Builder (storyboard বা XIB) বা প্রোগ্রাম্যাটিকভাবে তৈরি করা হয়। Model — যেকোনো ডেটা অবজেক্ট: নেটওয়ার্ক পরিষেবা, CoreData স্ট্যাক, Swift স্ট্রাকচার।

final class UserViewController: UIViewController {
    // View (storyboard outlet এর মাধ্যমে)
    @IBOutlet private var nameLabel: UILabel!
    @IBOutlet private var emailLabel: UILabel!

    // Model
    private let userService = UserService()

    override func viewDidLoad() {
        super.viewDidLoad()
        loadUser()
    }

    private func loadUser() {
        userService.fetchUser { [weak self] user in
            // Controller View আপডেট করে
            self?.nameLabel.text = user.name
            self?.emailLabel.text = user.email
        }
    }
}

Apple MVC-এর সমস্যা — View এবং Controller দৃঢ়ভাবে সংযুক্ত। UIViewController একসঙ্গে View এবং লজিক উভয়ই পরিচালনা করে। Storyboard View-কে XML-এ সংরক্ষণ করে, কিন্তু কন্ট্রোলারের IBOutlets-এর মাধ্যমে UI এলিমেন্টে সরাসরি রেফারেন্স থাকে। এটি একক দায়িত্ব নীতি লঙ্ঘন করে: কন্ট্রোলার লাইফসাইক, ডেলিগেট, ডেটাসোর্স, target-action এবং অ্যানিমেশনের জন্য দায়ী। ফলস্বরূপ, একটি আদর্শ iOS অ্যাপ স্ক্রিনে কন্ট্রোলারে 200–500 লাইন থাকে।

ViewController লাইফসাইক — Apple ৬টি লাইফসাইক পদ্ধতি প্রদান করে: loadView (ম্যানুয়াল View তৈরি), viewDidLoad (মেমরিতে View লোড করার পর), viewWillAppear (স্ক্রিনে উপস্থিত হওয়ার আগে), viewDidAppear (অ্যানিমেশনের পর), viewWillDisappear (স্ক্রিন ছাড়ার আগে), viewDidDisappear (ছাড়ার পর)। প্রতিটি পদ্ধতি MVC-তে লজিক রাখার স্থান। বিজনেস লজিকের জন্য এই পদ্ধতিগুলি ব্যবহার করা কন্ট্রোলারের বৃদ্ধি ত্বরান্বিত করে।

Android-এ MVC: Activity, Fragment এবং XML Layout

Android MVC — Activity এবং Fragment Controller হিসেবে কাজ করে, XML layout ফাইল View হিসেবে, ডেটাসহ যেকোনো POJO ক্লাস Model হিসেবে। Activity স্ক্রিন লাইফসাইক পরিচালনা করে: onCreate, onStart, onResume, onPause, onStop, onDestroy। Fragment নিজস্ব লাইফসাইকসহ Activity-এর ভিতরে একটি উপ-স্ক্রিন। View (XML) Controller থেকে পৃথক এবং setContentView বা LayoutInflater-এর মাধ্যমে লোড হয়। Model — রিপোজিটরি, ডেটাবেস, নেটওয়ার্ক কল।

class UserActivity : AppCompatActivity() {
    // View XML layout এর মাধ্যমে
    private lateinit var binding: ActivityUserBinding

    // Model
    private val userRepository = UserRepository()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityUserBinding.inflate(layoutInflater)
        setContentView(binding.root)
        loadUser()
    }

    private fun loadUser() {
        userRepository.getUser { user ->
            runOnUiThread {
                binding.nameText.text = user.name
                binding.emailText.text = user.email
            }
        }
    }
}

Android ViewBinding এবং DataBinding — আধুনিক টুল যা Controller এবং View-এর মধ্যে সংযোগ হ্রাস করে। ViewBinding XML থেকে Views-এর সরাসরি রেফারেন্সসহ একটি ক্লাস জেনারেট করে, findViewById দূর করে। DataBinding XML মার্কআপে @{user.name}-এর মাধ্যমে UI-তে ডেটা বাঁধার ক্ষমতা যোগ করে। DataBinding MVVM-এর দিকে একটি পদক্ষেপ, কারণ এটি Activity-তে কোড ছাড়াই Model থেকে View-তে ডেটা পাঠানোর অনুমতি দেয়। Google সব নতুন প্রকল্পের জন্য DataBinding সুপারিশ করে।

Android লাইফসাইক iOS-এর চেয়ে জটিল: স্ক্রিন রোটেশন, মেমরির অভাব বা কনফিগারেশন পরিবর্তনে Activity ধ্বংস এবং পুনর্নির্মিত হতে পারে। বিশুদ্ধ MVC-তে, কন্ট্রোলার (Activity) লজিক ধারণ করে যা ধ্বংসের সময় হারিয়ে যায়। এর জন্য onSaveInstanceState বা Jetpack থেকে ViewModel-এর মাধ্যমে অবস্থা সংরক্ষণের প্রয়োজন হয়, যা বিশুদ্ধ MVC-এর বাইরে এবং আর্কিটেকচারকে MVVM-এর কাছাকাছি নিয়ে আসে।

Massive View Controller এবং MVC-এর সীমাবদ্ধতা

Massive View Controller একটি শব্দ যা মোবাইল ডেভেলপমেন্টে MVC-এর প্রধান সমস্যা বর্ণনা করে। iOS এবং Android-এ কন্ট্রোলার অনেক বেশি দায়িত্ব গ্রহণ করে: ইনপুট প্রক্রিয়াকরণ, ডেটা বৈধতা, নেটওয়ার্ক মিথস্ক্রিয়া, নেভিগেশন, ক্যাশিং, অ্যানিমেশন, লাইফসাইক পরিচালনা। ফলস্বরূপ, কন্ট্রোলার 500–2000 লাইন কোডে পরিণত হয়, পড়া, পরীক্ষা এবং রক্ষণাবেক্ষণ কঠিন হয়ে পড়ে।

Massive View Controller-এর কারণ — UIKit এবং Android Framework-এর আর্কিটেকচার কন্ট্রোলারে লজিক রাখতে উৎসাহিত করে। নেটওয়ার্ক কল, JSON প্রক্রিয়াকরণ, নেভিগেশন — এগুলি স্বাভাবিকভাবেই Activity বা UIViewController-এ যায় কারণ তাদের লাইফসাইক এবং UI-তে অ্যাক্সেস থাকে। ডেভেলপারকে সচেতনভাবে লজিক পৃথক ক্লাসে (Service, Manager, Interactor) স্থানান্তর করতে হবে, যার জন্য শৃঙ্খলা এবং আর্কিটেকচারাল নীতির বোধগম্যতা প্রয়োজন।

MVC পরীক্ষা — Model ইউনিট টেস্ট দিয়ে বিচ্ছিন্নভাবে পরীক্ষা করা হয়। UIKit/UIFoundation-এর উপর নির্ভরতার কারণে Controller পরীক্ষা করা কঠিন। XCTest ভিউ উইন্ডো ছাড়া UIViewController তৈরি করতে দেয় না। Android-এর জন্য, ActivityTestRule এবং Robolectric আংশিকভাবে সমস্যার সমাধান করে, কিন্তু পরীক্ষা ধীর। View সাধারণত ইউনিট টেস্ট দিয়ে পরীক্ষা করা হয় না — UI-এর জন্য স্ক্রিনশট এবং UI টেস্ট (XCUITest, Espresso) ব্যবহার করা হয়।

MVC কখন ন্যায্য — এক বা দুটি উপাদানযুক্ত সাধারণ স্ক্রিন (লগইন স্ক্রিন, প্রোফাইল, সেটিংস)। হাইপোথিসিস যাচাইয়ের জন্য প্রোটোটাইপ এবং MVP — MVC অতিরিক্ত স্তর ছাড়া লিখতে দ্রুত। 10–15 স্ক্রিন পর্যন্ত ছোট কোডবেসের প্রকল্প। জটিল প্রকল্পগুলিতে, MVC প্রযুক্তিগত ঋণ জমার দিকে নিয়ে যায় এবং প্রতি 6–12 মাসে রিফ্যাক্টরিং প্রয়োজন।

MVVM, MVP এবং Clean Architecture-এর সাথে MVC-এর তুলনা

MVC vs MVVM — প্রধান পার্থক্য: MVVM-তে, কন্ট্রোলার ViewModel দ্বারা প্রতিস্থাপিত হয় যার View-এর কোনো রেফারেন্স নেই। Observable (SwiftUI), LiveData/StateFlow (Android) বা Combine/RxSwift-এর মাধ্যমে ডেটা প্রেরণ করা হয়। ViewModel UI নির্ভরতা ছাড়াই ইউনিট টেস্ট দিয়ে পরীক্ষা করা যায়। Apple 2019 সাল থেকে SwiftUI-এর সাথে MVVM সুপারিশ করে, Google — LiveData/Flow-এর সাথে MVVM অফিসিয়াল Android আর্কিটেকচার হিসেবে। MVVM-এর বাইন্ডিংয়ের জন্য বেশি কোড প্রয়োজন কিন্তু পরীক্ষাযোগ্যতা উল্লেখযোগ্যভাবে উন্নত করে।

MVC vs MVP — MVP (Model-View-Presenter)-এ, Presenter একটি পরীক্ষাযোগ্য স্তর যা একটি ইন্টারফেসের মাধ্যমে View গ্রহণ করে। MVC-এর বিপরীতে যেখানে Controller UIKit-এর মাধ্যমে সরাসরি View পরিচালনা করে, Presenter ফ্রেমওয়ার্কের উপর নির্ভর করে না — এটি ViewInterface অ্যাবস্ট্রাকশনের মাধ্যমে কাজ করে। Jetpack-এর আগে Android ডেভেলপমেন্টে MVP জনপ্রিয় ছিল এবং লিগ্যাসি প্রকল্পগুলিতে ব্যবহৃত হয়। Presenter Activity-র চেয়ে বেশি দিন বাঁচে এবং স্ক্রিন ঘূর্ণনে অবস্থা সংরক্ষণ করে।

MVC vs Clean Architecture — Clean Architecture স্তর যুক্ত করে: Use Cases (Interactors), Entities, Gateways এবং Repository। MVC Presentation স্তরে থাকে, কিন্তু বিজনেস লজিক Use Cases-সহ Domain স্তরে স্থানান্তরিত হয়। Clean Architecture Massive View Controller সমস্যা মৌলিকভাবে সমাধান করে — Controller-এ শুধুমাত্র Use Cases কল এবং View আপডেট থাকে। অসুবিধা — ক্লাস এবং ফাইলের সংখ্যা উল্লেখযোগ্য বৃদ্ধি, যা 50+ স্ক্রিনের প্রকল্পের জন্য ন্যায্য।

// iOS-এ MVC: Controller সবকিছু ধারণ করে
class OrderViewController: UIViewController {
    func placeOrder() {
        // বৈধতা + নেটওয়ার্ক + UI আপডেট
        guard Validation.isValid(total) else { return }
        NetworkService.shared.submit(order) { [weak self] result in
            self?.handleResult(result)
        }
    }
}

// MVVM: ViewModel-এ লজিক
class OrderViewModel: ObservableObject {
    @Published var state: OrderState = .idle
    func placeOrder() { /* ব্যবসায়িক লজিক */ }
}

আর্কিটেকচার নির্বাচন টিমের আকার, প্রকল্পের পরিধি এবং প্রয়োজনীয় পরীক্ষাযোগ্যতার উপর নির্ভর করে। 1–2 ডেভেলপারের টিম এবং 20 স্ক্রিন পর্যন্ত প্রকল্পের জন্য, MVVM ভাল কাজ করে। 5+ ডেভেলপারের বড় টিম এবং 50+ স্ক্রিনের প্রকল্পের জন্য — মডুলার কাঠামো সহ Clean Architecture। MVC প্রাসঙ্গিক রয়ে গেছে আর্কিটেকচারের বিবর্তন বোঝার জন্য, লিগ্যাসি প্রকল্প রক্ষণাবেক্ষণের জন্য এবং জটিল বিজনেস লজিক ছাড়া সাধারণ UIKit স্ক্রিনের জন্য।