कोटलिन में आर्किटेक्चरल पैटर्न: MVC, MVP, MVVM और MVI

अराजकता में कैसे न डूबें: कोटलिन में आर्किटेक्चरल पैटर्न

क्या आपने कभी अपना प्रोजेक्ट लिखने के एक महीने बाद खोला और यह समझ नहीं पाए कि लॉगिन लॉजिक कहाँ है? या एक नया बटन जोड़ने की कोशिश की, और उसने लिस्ट के काम को तोड़ दिया? परिचित लगता है? बिना आर्किटेक्चर वाली ऐप की दुनिया में आपका स्वागत है।

कोटलिन में आर्किटेक्चरल पैटर्न फैशन का चलन या अमूर्त सिद्धांत नहीं हैं। ये 'स्पेगेटी कोड' से मुक्ति हैं, जहाँ सब कुछ मिला हुआ होता है: बिज़नेस लॉजिक, UI, नेटवर्क और डेटाबेस का काम। इस लेख में हम चार मुख्य पैटर्न देखेंगे: MVC, MVP, MVVM और MVI। आप इन्हें कोटलिन के वास्तविक उदाहरणों में काम करते देखेंगे, मुख्य अंतर समझेंगे और अपने कार्य के लिए सही उपकरण चुन सकेंगे। चलिए शुरू करते हैं!

आर्किटेक्चरल पैटर्न क्या है और इसकी आवश्यकता क्यों है?

आर्किटेक्चरल पैटर्न आपके ऐप का ढाँचा है। यह तय करता है कि क्लासेस एक-दूसरे से कैसे संवाद करेंगी, डेटा कहाँ स्टोर होगा और डिस्प्ले के लिए कौन जिम्मेदार होगा। इसके बिना, देर-सबेर आपको God Object मिलेगा - एक ऐसा क्लास जो सब कुछ करता है। या Callback Hell - जब एक कॉलबैक दूसरे को जन्म देता है, और कोड अपठनीय हो जाता है।

कोटलिन, अपने संक्षिप्त सिंटैक्स और नल सेफ्टी के साथ, स्वच्छ आर्किटेक्चर के लिए आदर्श है। लेकिन भाषा केवल आधा काम है। दूसरा आधा हिस्सा पैटर्न का सही चुनाव है।

MVC (Model-View-Controller) — क्लासिक शैली

सबसे पुराना और सरल पैटर्न। इसका सार:

\n
• Model — डेटा और बिज़नेस लॉजिक।
\n
• View — प्रदर्शन (Activity, Fragment, Compose)।
\n
• Controller — जोड़ने वाली कड़ी, उपयोगकर्ता इनपुट को संसाधित करता है।
\n

कोटलिन में (विशेषकर Android के लिए) MVC अक्सर 'मोटा Controller' बन जाता है। Activity ही View और Controller दोनों बन जाती है। उदाहरण:

// बुरा: Activity ही View और Controller दोनों है\nclass LoginActivity : AppCompatActivity() {\n    private lateinit var emailEditText: EditText\n    private lateinit var passwordEditText: EditText\n\n    override fun onCreate(savedInstanceState: Bundle?) {\n        super.onCreate(savedInstanceState)\n        setContentView(R.layout.activity_login)\n\n        // Controller लॉजिक यहीं\n        findViewById<Button>(R.id.loginButton).setOnClickListener {\n            val email = emailEditText.text.toString()\n            val password = passwordEditText.text.toString()\n            // वैलिडेशन और API कॉल — सब एक ही जगह\n            if (email.isNotEmpty() && password.isNotEmpty()) {\n                loginUser(email, password)\n            }\n        }\n    }\n\n    private fun loginUser(email: String, password: String) {\n        // नेटवर्क का काम — सीधे Activity में\n        CoroutineScope(Dispatchers.IO).launch {\n            val result = api.login(email, password)\n            withContext(Dispatchers.Main) {\n                // UI अपडेट — यहाँ भी\n                Toast.makeText(this@LoginActivity, result.message, Toast.LENGTH_SHORT).show()\n            }\n        }\n    }\n}\n

लाभ: सरलता, कम प्रवेश सीमा।

नुकसान: View और Controller कसकर जुड़े होते हैं। Android एमुलेटर के बिना लॉजिक का परीक्षण असंभव है। बड़े प्रोजेक्ट्स के लिए — नरक।

MVP (Model-View-Presenter) — शक्तियों का विभाजन

MVP, MVC की मुख्य समस्या को हल करता है: View को इंटरफेस के माध्यम से लॉजिक से अलग किया जाता है। Presenter 'दिमाग' है, जो Android के बारे में कुछ नहीं जानता। View एक निष्क्रिय परत है।

कोटलिन में उदाहरण:

// संचार के लिए इंटरफेस\ninterface LoginView {\n    fun showLoading()\n    fun hideLoading()\n    fun showError(message: String)\n    fun navigateToHome()\n}\n\nclass LoginPresenter(private val view: LoginView, private val authRepository: AuthRepository) {\n\n    fun login(email: String, password: String) {\n        view.showLoading()\n        CoroutineScope(Dispatchers.IO).launch {\n