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 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 @{user.name} کے ذریعے XML مارک اپ میں ڈیٹا کو 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 یونٹ ٹیسٹ سے الگ تھلگ جانچا جاتا ہے۔ Controller UIKit/UIFoundation پر انحصار کی وجہ سے جانچنا مشکل ہے۔ 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 اسکرینوں کے لیے۔