Modèles architecturaux en Kotlin : MVC, MVP, MVVM et MVI

Comment ne pas se noyer dans le chaos : les modèles architecturaux en Kotlin

Avez-vous déjà ouvert votre projet un mois après l'avoir écrit sans pouvoir comprendre où se trouve la logique d'authentification ? Ou avez-vous essayé d'ajouter un nouveau bouton qui cassait le fonctionnement de la liste ? Cela vous dit quelque chose ? Bienvenue dans le monde des applications sans architecture.

Les modèles architecturaux en Kotlin ne sont ni une mode ni des théories abstraites. Ce sont des solutions pour éviter le « code spaghetti », où tout est mélangé : logique métier, UI, travail réseau et base de données. Dans cet article, nous allons analyser quatre modèles principaux : MVC, MVP, MVVM et MVI. Vous les verrez en action avec des exemples concrets en Kotlin, comprendrez leurs différences clés et pourrez choisir l'outil adapté à votre tâche. C'est parti !

Qu'est-ce qu'un modèle architectural et pourquoi en a-t-on besoin ?

Un modèle architectural est le squelette de votre application. Il dicte comment les classes communiquent entre elles, où stocker les données et qui est responsable de l'affichage. Sans lui, tôt ou tard, vous obtiendrez un God Object — une classe qui fait tout. Ou un Callback Hell — où des callbacks en génèrent d'autres, rendant le code illisible.

Kotlin, avec sa syntaxe concise et sa sécurité nulle, est parfaitement adapté à une architecture propre. Mais le langage n'est que la moitié du travail. L'autre moitié est le choix correct du modèle.

MVC (Model-View-Controller) — le classique du genre

Le modèle le plus ancien et le plus simple. Son essence :

• Model — les données et la logique métier.
• View — l'affichage (Activity, Fragment, Compose).
• Controller — l'élément de liaison, traite les entrées utilisateur.

En Kotlin (surtout pour Android), MVC se transforme souvent en « Controller épais ». L'Activity devient à la fois View et Controller. Exemple :

// Mauvais : Activity est à la fois View et Controllerclass LoginActivity : AppCompatActivity() {    private lateinit var emailEditText: EditText    private lateinit var passwordEditText: EditText

    override fun onCreate(savedInstanceState: Bundle?) {        super.onCreate(savedInstanceState)        setContentView(R.layout.activity_login)

        // Logique Controller directement ici        findViewById<Button>(R.id.loginButton).setOnClickListener {            val email = emailEditText.text.toString()            val password = passwordEditText.text.toString()            // Validation et appel API — tout au même endroit            if (email.isNotEmpty() && password.isNotEmpty()) {                loginUser(email, password)            }        }    }

    private fun loginUser(email: String, password: String) {        // Travail réseau — directement dans l'Activity        CoroutineScope(Dispatchers.IO).launch {            val result = api.login(email, password)            withContext(Dispatchers.Main) {                // Mise à jour UI — également ici                Toast.makeText(this@LoginActivity, result.message, Toast.LENGTH_SHORT).show()            }        }    }}

Avantages : simplicité, faible seuil d'entrée.

Inconvénients : View et Controller sont fortement couplés. Impossible de tester la logique sans émulateur Android. Pour les grands projets — un enfer.

MVP (Model-View-Presenter) — séparation des pouvoirs

MVP résout le problème principal de MVC : la View est séparée de la logique via des interfaces. Le Presenter est le « cerveau » qui ne connaît rien d'Android. La View est une couche passive.

Exemple en Kotlin :

// Interfaces pour la communicationinterface LoginView {    fun showLoading()    fun hideLoading()    fun showError(message: String)    fun navigateToHome()}

class LoginPresenter(private val view: LoginView, private val authRepository: AuthRepository) {

    fun login(email: String, password: String) {        view.showLoading()        CoroutineScope(Dispatchers.IO).launch {