Rethinking MVVM Architecture: Clarifying Layer Responsibilities

ZjzMisaka — Thu, 07 May 2026 20:02:11 +0000

The MVVM pattern is widely adopted in modern application development. However, in my practical development experience, there is a certain degree of misunderstanding within the team regarding the responsibilities of each layer. This has led to an imbalanced code structure, resulting in extremely bloated ViewModel layers and the degeneration of the Model layer into pure data containers.
Based on the core principles of object-oriented design and architectural layering, this article reorganizes and redefines the responsibilities of each MVVM layer.

For explanations regarding the "Anemic Domain Model" and "Rich Object" mentioned below, please refer to: Anemic Domain Model.

Overall, design patterns like MVVM are intended for development convenience and maintainability. They might introduce some complexity, but if coding becomes a painful experience just to comply with a design pattern, it is highly likely that the pattern is being dogmatically misused.

Common Misconceptions

Misconception 1: The Model Layer Should Only Contain Data

The Model layer represents the data model and should only contain data fields and properties, strictly corresponding one to one with UI elements or database table fields.

Before being a model, a Model is fundamentally an object-oriented type. It abstracts certain sub business concepts, and these sub businesses inevitably have their own business logic.

Simplifying the Model into a pure data container (i.e., Anemic Domain Model) ignores the core philosophy of object-oriented design. Once all business rules and logic are moved out to the ViewModel, it not only causes an imbalance in responsibilities but also makes it impossible to independently test and reuse the business logic.

Misconception 2: The ViewModel Layer Should Bear All Business Logic

The ViewModel layer is responsible for managing Model instances and their collections, handling all business logic, and directly updating Model data to drive UI refreshes.

Concentrating all business logic in the ViewModel leads to extreme bloat. As features iterate, a single ViewModel file can easily reach thousands or tens of thousands of lines, making it difficult to maintain and impossible to perform effective unit testing on the business logic.

Misconception 3: The View's CodeBehind Should Remain Empty

The `.xaml.cs` files should be kept as empty as possible, and all interaction logic should be transferred to the ViewModel via Attached Behaviors or Commands.*

I suspect that this kind of obsession originates from trying to get around code coverage requirements for unit tests, since UI code isn’t that easy to test anyway XD.

This practice confuses the concepts of "business logic" and "UI control logic". Forcing purely UI interaction logic into the ViewModel, or wrapping it in layers of Behaviors, only increases system complexity and contradicts the original intent of MVVM.

The MVVM advocacy to "keep CodeBehind clean" originally meant avoiding the mixing of business logic into the UI's CodeBehind, not prohibiting the writing of UI control logic itself.

Correct Understanding of MVVM Architecture

Overview of Responsibility Boundaries

Layer	Core Abstraction	Primary Responsibilities	Should Not Contain
Model	Business Concepts	Business data, business logic, business rules	UI state, UI control logic
ViewModel	UI Actions	UI state management, Commands, coordinating Model invocations	Specific business rules, pure UI control logic
View	UI Control	UI interaction logic, visual presentation control	Business logic, business state

Model Layer: Abstraction of Business Concepts

The core responsibility of the Model layer is to abstract business concepts. It is not just a data container, but a complete object-oriented type that carries the business data and business logic within its business domain. Furthermore, the Model further abstracts sub business concepts, which also possess their own business rules.

Responsibility Boundaries:

Encapsulate business data and state.
Implement business rules and operations belonging to this business domain.
Further abstract sub business concepts and maintain the sub businesses' own logic.
Provide business operation interfaces for the ViewModel to invoke.

Design Principles:

The Model should be a Rich Domain Object, not an Anemic Domain Model.

The ViewModel does not need to know these business details; it simply calls the corresponding interfaces to intuitively control the UI display and actions in a manner consistent with business intuition.

ViewModel Layer: Coordinating UI Actions

The core responsibility of the ViewModel layer is to abstract and coordinate UI actions. It maintains additional UI states required by the interface and organizes UI actions and state changes by invoking the business logic of various Models. The ViewModel is a bridge between the View and the Model, not a container for business logic.

Responsibility Boundaries:

Maintain UI specific states that are not strongly related to specific business logic (e.g., IsLoading, IsSelected, ErrorMessage, etc.).
Expose Commands to respond to user operations.
Invoke business methods of the Model and coordinate interactions between multiple Models.
Handle page/view navigation logic.
Should not contain specific business rules.

Design Principles:

The ViewModel should be a lightweight Coordinator, not a dumping ground for business logic. If a large amount of business judgment and rule code is found in the ViewModel, it should be pushed down to the corresponding Model layer. A reasonable ViewModel should primarily consist of property bindings, Command definitions, management of Model instances, and invocations of public functions exposed by the Model.

View Layer: Pure UI Control Logic

The core responsibility of the View layer is to handle user input and output logic at the UI level. CodeBehind should not contain business logic, but for logic that falls purely within the scope of UI control, implementing it directly in CodeBehind is completely reasonable.

Responsibility Boundaries:

Handle pure UI interaction logic (e.g., focus management, animation triggering, control linkage, etc.).
Handle visual interaction behaviors that are impossible or difficult to express through data binding.
Should not contain business rules and business state management.

Design Principles:

The core criterion for determining whether a piece of logic should be placed in CodeBehind is: Is this logic solely related to UI presentation and unrelated to the business? If so, placing it in the View layer is appropriate. Only when a piece of UI logic needs to be reused across multiple Views should you consider encapsulating it as an Attached Behavior.

Forem: ZjzMisaka

Rethinking MVVM Architecture: Clarifying Layer Responsibilities

Common Misconceptions

Misconception 1: The Model Layer Should Only Contain Data

Misconception 2: The ViewModel Layer Should Bear All Business Logic

Misconception 3: The View's CodeBehind Should Remain Empty

Correct Understanding of MVVM Architecture

Model Layer: Abstraction of Business Concepts

ViewModel Layer: Coordinating UI Actions

View Layer: Pure UI Control Logic