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 की अनुशंसा नहीं करता — आधिकारिक दस्तावेज़ MVVM को Jetpack के साथ सुझाता है। हालाँकि, विरासती परियोजनाओं के साथ काम करने और आर्किटेक्चरल पैटर्न के विकास को समझने के लिए 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 6 जीवनचक्र विधियाँ प्रदान करता है: 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 महीनों में रीफ़ैक्टरिंग की आवश्यकता होती है।

MVC की MVVM, MVP और Clean Architecture से तुलना

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 स्क्रीन के लिए।