Model View ViewModel - Revision history

Root at 17:22, 19 January 2026

2026-01-19T17:22:58Z

← Older revision		Revision as of 18:22, 19 January 2026
Line 1:		Line 1:
	~~= MVVM Architecture =~~

	MVVM (Model-View-ViewModel) is a software architectural pattern intended to facilitate the separation of the development of the graphical user interface (the View) from the development of the business logic or back-end logic (the Model). The ViewModel serves as the intermediary component that handles the communication between the Model and the View. This separation of concerns helps manage complexity, improve testability, and facilitate easier maintenance of applications containing complex user interfaces. It is widely adopted in modern client-side development, particularly in Android (supported by Jetpack libraries), iOS (via SwiftUI or various frameworks), and Windows development (WPF, UWP).		MVVM (Model-View-ViewModel) is a software architectural pattern intended to facilitate the separation of the development of the graphical user interface (the View) from the development of the business logic or back-end logic (the Model). The ViewModel serves as the intermediary component that handles the communication between the Model and the View. This separation of concerns helps manage complexity, improve testability, and facilitate easier maintenance of applications containing complex user interfaces. It is widely adopted in modern client-side development, particularly in Android (supported by Jetpack libraries), iOS (via SwiftUI or various frameworks), and Windows development (WPF, UWP).

	== Core Components ==		= Core Components =
	MVVM breaks down the application into three distinct layers with strict dependency rules.		MVVM breaks down the application into three distinct layers with strict dependency rules.
	[[File:Mvvm architecture.png\|none\|thumb]]		[[File:Mvvm architecture.png\|none\|thumb]]

	=== Model ===		== Model ==
	The Model represents the data domain and the business logic of the application. It is the single source of truth for data.		The Model represents the data domain and the business logic of the application. It is the single source of truth for data.
	* '''Responsibilities''': It holds the raw data structures, performs data validation, and manages data retrieval and storage from various sources like local databases (e.g., Room/SQLite), network APIs (e.g., REST/GraphQL), or repositories.		* '''Responsibilities''': It holds the raw data structures, performs data validation, and manages data retrieval and storage from various sources like local databases (e.g., Room/SQLite), network APIs (e.g., REST/GraphQL), or repositories.
	* '''Knowledge''': The Model is completely ignorant of the ViewModel and the View. It has no dependencies on UI components.		* '''Knowledge''': The Model is completely ignorant of the ViewModel and the View. It has no dependencies on UI components.

	=== View ===		== View ==
	The View is the visual layer that the user interacts with. It is responsible for the structure, layout, and appearance of what users see on the screen.		The View is the visual layer that the user interacts with. It is responsible for the structure, layout, and appearance of what users see on the screen.
	* '''Responsibilities''': It renders the UI elements and captures user input events (like clicks, gestures, or text input). The View should be "passive" or "dumb," meaning it should contain zero business logic. Its only job is to display whatever state the ViewModel provides and forward user actions to the ViewModel.		* '''Responsibilities''': It renders the UI elements and captures user input events (like clicks, gestures, or text input). The View should be "passive" or "dumb," meaning it should contain zero business logic. Its only job is to display whatever state the ViewModel provides and forward user actions to the ViewModel.
	* '''Knowledge''': The View knows about the ViewModel. It subscribes to or observes changes in the ViewModel's state. In Android, the View is typically an `Activity`, `Fragment`, or Jetpack Compose functions.		* '''Knowledge''': The View knows about the ViewModel. It subscribes to or observes changes in the ViewModel's state. In Android, the View is typically an `Activity`, `Fragment`, or Jetpack Compose functions.

	=== ViewModel ===		== ViewModel ==
	The ViewModel acts as the bridge or glue between the View and the Model. It is an abstraction of the View exposing public properties and commands.		The ViewModel acts as the bridge or glue between the View and the Model. It is an abstraction of the View exposing public properties and commands.
	* '''Responsibilities''': It retrieves data from the Model, processes it into a format ready for display by the View, and holds the current state of the UI. It also handles user actions forwarded by the View, translating them into operations on the Model.		* '''Responsibilities''': It retrieves data from the Model, processes it into a format ready for display by the View, and holds the current state of the UI. It also handles user actions forwarded by the View, translating them into operations on the Model.
	* '''Knowledge''': The ViewModel knows about the Model. Crucially, ''the ViewModel does not know about the View''. It holds no reference to UI components (like TextViews or Buttons) or platform-specific UI contexts (like an Android `Context`). This independence ensures that the ViewModel can be unit-tested in isolation.		* '''Knowledge''': The ViewModel knows about the Model. Crucially, ''the ViewModel does not know about the View''. It holds no reference to UI components (like TextViews or Buttons) or platform-specific UI contexts (like an Android `Context`). This independence ensures that the ViewModel can be unit-tested in isolation.

	== The ~~Data Flow Mechanism =~~=		= The data flow mechanism =
	The power of MVVM lies in its specific directional data flow, achieved through an "observer pattern."		The power of MVVM lies in its specific directional data flow, achieved through an "observer pattern."

	1. '''User ~~Action~~''': The user interacts with the '''View''' (e.g., presses a button).		1. '''User action''': The user interacts with the '''View''' (e.g., presses a button).

	2. '''Command forwarding''': The View calls a method on the '''ViewModel''' to handle this action.		2. '''Command forwarding''': The View calls a method on the '''ViewModel''' to handle this action.

	3. '''''Model interaction''''': The '''ViewModel''' processes the action and, if necessary, requests updates or new data from the ''Model''.		3. '''Model interaction''': The '''ViewModel''' processes the action and, if necessary, requests updates or new data from the ''Model''.

	4. '''Data update''': The '''Model''' performs the business logic and updates the data.		4. '''Data update''': The '''Model''' performs the business logic and updates the data.
Line 44:		Line 42:
	* '''Handling lifecycle events''': In frameworks like Android, ViewModels are designed to survive configuration changes (like screen rotations), ensuring data isn't lost when the UI is recreated.		* '''Handling lifecycle events''': In frameworks like Android, ViewModels are designed to survive configuration changes (like screen rotations), ensuring data isn't lost when the UI is recreated.

	== Kotlin example implementation ==		= Comparison: MVVM vs. MVC =
			While both patterns aim to separate UI from business logic, they differ significantly in how the components communicate and where the control logic resides.

			In '''MVC''' (Model-View-Controller), the '''Controller''' is responsible for determining which View to display and acts as the entry point for user input. In many MVC implementations, the View and the Controller are tightly coupled, and the Controller may manipulate the View directly.

			In '''MVVM''', the '''ViewModel''' does not control the View directly. Instead, it exposes a state that the View binds to. This "data-binding" mechanism is the key differentiator.

			[[File:Differences mvvm mvc.png\|frameless]]

			{\| class="wikitable"
			! Feature !! MVC (Model-View-Controller) !! MVVM (Model-View-ViewModel)
			\|-
			\| '''Primary goal'''\|\| Separation of concerns via a Controller that mediates input. \|\| Separation of concerns via Data Binding and State Observation.
			\|-
			\| '''View dependency'''\|\| The View typically knows about the Model (to display data) and the Controller (to send input). \|\| The View knows about the ViewModel but '''not''' the Model.
			\|-
			\| '''Logic location'''\|\| The Controller handles input logic and decides what the View should display. \|\| The ViewModel handles presentation logic and holds the state; the View decides '''how''' to display it.
			\|-
			\| '''Communication'''\|\| '''One-to-many''': One Controller can select different Views. \|\| '''One-to-many''': One ViewModel can be observed by multiple Views (though usually 1:1 in Android).
			\|-
			\| '''Coupling'''\|\| High: Controllers are often tied to specific Views and lifecycles. \|\| Low: The ViewModel has no reference to the View, making it platform-independent.
			\|-
			\| '''Testability'''\|\| Lower: Testing the Controller often requires mocking the View/UI framework. \|\| Higher: The ViewModel is just a class with data and methods, easily unit tested without UI mocks.
			\|}

			= Kotlin example implementation =
	Below is a simplified example of a counter application in Kotlin for Android, demonstrating the three layers.		Below is a simplified example of a counter application in Kotlin for Android, demonstrating the three layers.

	[[File:Mvvm image.png\|frameless]]		[[File:Mvvm image.png\|frameless]]

	=== The Model (Data Layer) ===		== The Model (Data Layer) ==
	A simple repository that holds the count value. In a real app, this might interact with a database.		A simple repository that holds the count value. In a real app, this might interact with a database.
	<syntaxhighlight lang="kotlin">		<syntaxhighlight lang="kotlin">
Line 66:		Line 89:
	</syntaxhighlight>		</syntaxhighlight>

	=== The ViewModel ===		== The ViewModel ==
	The ViewModel holds the UI state using `MutableStateFlow`, which is a modern, observable data holder in Kotlin coroutines. It exposes an immutable `StateFlow` to the View.		The ViewModel holds the UI state using `MutableStateFlow`, which is a modern, observable data holder in Kotlin coroutines. It exposes an immutable `StateFlow` to the View.

Line 98:		Line 121:
	</syntaxhighlight>		</syntaxhighlight>

	=== The View (UI Layer) ===		== The View (UI Layer) ==
	A simple Android Activity that sets up the UI elements and observes the ViewModel's state. Note that the actual observation requires a coroutine scope (omitted here for brevity, but essential in practice).		A simple Android Activity that sets up the UI elements and observes the ViewModel's state. Note that the actual observation requires a coroutine scope (omitted here for brevity, but essential in practice).

Root: Created page with "= MVVM Architecture = MVVM (Model-View-ViewModel) is a software architectural pattern intended to facilitate the separation of the development of the graphical user interface (the View) from the development of the business logic or back-end logic (the Model). The ViewModel serves as the intermediary component that handles the communication between the Model and the View. This separation of concerns helps manage complexity, improve testability, and facilitate easier main..."

2026-01-19T17:06:37Z

Created page with "= MVVM Architecture = MVVM (Model-View-ViewModel) is a software architectural pattern intended to facilitate the separation of the development of the graphical user interface (the View) from the development of the business logic or back-end logic (the Model). The ViewModel serves as the intermediary component that handles the communication between the Model and the View. This separation of concerns helps manage complexity, improve testability, and facilitate easier main..."

New page

= MVVM Architecture =

MVVM (Model-View-ViewModel) is a software architectural pattern intended to facilitate the separation of the development of the graphical user interface (the View) from the development of the business logic or back-end logic (the Model). The ViewModel serves as the intermediary component that handles the communication between the Model and the View. This separation of concerns helps manage complexity, improve testability, and facilitate easier maintenance of applications containing complex user interfaces. It is widely adopted in modern client-side development, particularly in Android (supported by Jetpack libraries), iOS (via SwiftUI or various frameworks), and Windows development (WPF, UWP).

== Core Components ==
MVVM breaks down the application into three distinct layers with strict dependency rules.
[[File:Mvvm architecture.png|none|thumb]]

=== Model ===
The Model represents the data domain and the business logic of the application. It is the single source of truth for data.
* '''Responsibilities''': It holds the raw data structures, performs data validation, and manages data retrieval and storage from various sources like local databases (e.g., Room/SQLite), network APIs (e.g., REST/GraphQL), or repositories.
* '''Knowledge''': The Model is completely ignorant of the ViewModel and the View. It has no dependencies on UI components.

=== View ===
The View is the visual layer that the user interacts with. It is responsible for the structure, layout, and appearance of what users see on the screen.
* '''Responsibilities''': It renders the UI elements and captures user input events (like clicks, gestures, or text input). The View should be "passive" or "dumb," meaning it should contain zero business logic. Its only job is to display whatever state the ViewModel provides and forward user actions to the ViewModel.
* '''Knowledge''': The View knows about the ViewModel. It subscribes to or observes changes in the ViewModel's state. In Android, the View is typically an `Activity`, `Fragment`, or Jetpack Compose functions.

=== ViewModel ===
The ViewModel acts as the bridge or glue between the View and the Model. It is an abstraction of the View exposing public properties and commands.
* '''Responsibilities''': It retrieves data from the Model, processes it into a format ready for display by the View, and holds the current state of the UI. It also handles user actions forwarded by the View, translating them into operations on the Model.
* '''Knowledge''': The ViewModel knows about the Model. Crucially, ''the ViewModel does not know about the View''. It holds no reference to UI components (like TextViews or Buttons) or platform-specific UI contexts (like an Android `Context`). This independence ensures that the ViewModel can be unit-tested in isolation.

== The Data Flow Mechanism ==
The power of MVVM lies in its specific directional data flow, achieved through an "observer pattern."

1. '''User Action''': The user interacts with the '''View''' (e.g., presses a button).

2. '''Command forwarding''': The View calls a method on the '''ViewModel''' to handle this action.

3. '''''Model interaction''''': The '''ViewModel''' processes the action and, if necessary, requests updates or new data from the ''Model''.

4. '''Data update''': The '''Model''' performs the business logic and updates the data.

5. '''State change notification''': The '''ViewModel''' receives the updated data from the Model and updates its own internal state. Because the ViewModel's state properties are "observable" (using mechanisms like Kotlin `StateFlow`), the '''ViewModel''' automatically notifies any subscribers that its state has changed.

6. '''UI Refresh''': The '''''View,''''' which is observing the '''ViewModel''', receives the notification and automatically re-renders itself to reflect the new state.

== Benefits of MVVM ==

* '''Separation of concerns''': By decoupling UI logic from business logic, the codebase becomes cleaner and easier to navigate.
* '''Testability''': Because the ViewModel has no dependency on the View or platform-specific UI frameworks, business logic hosted in the ViewModel can be easily unit-tested with standard testing frameworks like JUnit.
* '''Maintainability''': UI changes can be made in the View without affecting the ViewModel or Model, and changes to business rules in the Model rarely affect the View directly.
* '''Handling lifecycle events''': In frameworks like Android, ViewModels are designed to survive configuration changes (like screen rotations), ensuring data isn't lost when the UI is recreated.

== Kotlin example implementation ==
Below is a simplified example of a counter application in Kotlin for Android, demonstrating the three layers.

[[File:Mvvm image.png|frameless]]

=== The Model (Data Layer) ===
A simple repository that holds the count value. In a real app, this might interact with a database.
<syntaxhighlight lang="kotlin">
class CounterRepository {
private var count = 0

fun getCurrentCount(): Int {
return count
}

fun incrementCount(): Int {
count++
return count
}
}
</syntaxhighlight>

=== The ViewModel ===
The ViewModel holds the UI state using `MutableStateFlow`, which is a modern, observable data holder in Kotlin coroutines. It exposes an immutable `StateFlow` to the View.

<syntaxhighlight lang="kotlin">
import androidx.lifecycle.ViewModel
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow
import kotlinx.coroutines.flow.asStateFlow

// The ViewModel inherits from the framework's base ViewModel class
class CounterViewModel(private val repository: CounterRepository = CounterRepository()) : ViewModel() {

// Mutable internal state
private val _uiState = MutableStateFlow(0)

// Immutable exposed state for the View to observe
val uiState: StateFlow<Int> = _uiState.asStateFlow()

init {
// Initialize state from the model
_uiState.value = repository.getCurrentCount()
}

// Method called by the View upon user interaction
fun onIncrementButtonPressed() {
val newCount = repository.incrementCount()
// Update the state; observers will be notified automatically
_uiState.value = newCount
}
}
</syntaxhighlight>

=== The View (UI Layer) ===
A simple Android Activity that sets up the UI elements and observes the ViewModel's state. Note that the actual observation requires a coroutine scope (omitted here for brevity, but essential in practice).

<syntaxhighlight lang="kotlin">
import android.os.Bundle
import android.widget.Button
import android.widget.TextView
import androidx.appcompat.app.AppCompatActivity
// Imports for ViewModel delegation and lifecycle scope would be here

class CounterActivity : AppCompatActivity() {

// Obtain an instance of the ViewModel
private val viewModel: CounterViewModel by viewModels()

private lateinit var countTextView: TextView
private lateinit var incrementButton: Button

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

// 1. Initialize UI elements
countTextView = findViewById(R.id.countTextView)
incrementButton = findViewById(R.id.incrementButton)

// 2. Handle User Actions (View -> ViewModel)
incrementButton.setOnClickListener {
viewModel.onIncrementButtonPressed()
}

// 3. Observe ViewModel State (ViewModel -> View)
// Note: In a real Android app, launch this in lifecycleScope.launch {}
viewModel.uiState.collect { count ->
// Update the UI whenever the state changes
countTextView.text = count.toString()
}
}
}
</syntaxhighlight>
[[Category:Kotlin]]