iOS中MVVM架构解析及相关技术问题问询

云原生阿岚

2026-5-21

iOS MVVM架构深度解析：你的问题全解答

Hey folks, let's break down your questions about MVVM in iOS—super glad you're digging into these details to get a solid grasp of the pattern!

1. Model与ViewModel的核心区别是什么？Model已承载数据，为何需在ViewModel中重复编写并更新相同属性（存在冗余代码问题）？

First off, let's clear up their core roles:

Model is your pure data container. It only holds raw data, enforces basic data validity (like checking if an email is formatted correctly), and has zero business or presentation logic. Think of it as a blueprint for your data—no frills, just structure and integrity checks.
ViewModel is the middleman between View and Model. Its job is to take raw Model data and transform it into a format the View can directly use, plus handle all business logic tied to user interactions.

As for the "redundancy" concern—this isn't duplication, it's adaptation. Here's why it's necessary:

Model data is often low-level: A Model might store a user's birthday as a Date object, but your View needs it as a localized string like "Oct 5, 2024". The ViewModel handles that conversion.
ViewModel combines data from multiple Models: For example, an order detail screen might need data from a UserModel (shipping address) and an OrderModel (items, total). The ViewModel aggregates these into a cohesive set of properties for the View.
ViewModel manages presentation state: Things like loading spinners, error messages, or button enable/disable status don't belong in a Model—these are presentation-specific states that the ViewModel tracks to keep the View in sync.

双向 binding isn't just for forms—here are some other super useful scenarios:

Real-time previews: Think of settings screens where adjusting a slider (like font size) instantly updates a preview text box, or photo editing tools where tweaking brightness/contrast shows the effect in real time.
Dynamic form flows: If your form shows or hides fields based on user selections (e.g., showing a "company name" field only if the user selects "business account"), binding keeps the View's UI state in lockstep with the ViewModel's logic.
Live data dashboards: For apps displaying real-time data like stock prices, sports scores, or live chat messages—binding ensures the View updates automatically when the ViewModel receives new data, and user actions (like switching timeframes) sync back to trigger new data requests.
Multi-component UIs: In a shopping cart, changing an item's quantity via a stepper should instantly update the total price label, and disable the "checkout" button if inventory runs out. Binding handles all these syncs without manual delegate calls.

KVO works, but it's far from the best tool for the job these days. Here's why it's not ideal:

Boilerplate & memory risk: You have to manually add and remove observers, and it's easy to forget the cleanup step—leading to memory leaks or crashes if the View outlives the ViewModel (or vice versa).
Debugging hell: All KVO updates funnel into a single observeValue(forKeyPath:of:change:context:) method. If you're observing multiple properties, you end up with a messy pile of if-else checks that's hard to trace when things go wrong.
Type unsafety: Older KVO uses string-based key paths—typos won't be caught at compile time, leading to runtime crashes. Even with Swift's type-safe KeyPaths, it's still less robust than reactive frameworks like Combine or RxSwift.
One-way by default: KVO only handles observing changes from ViewModel to View. To make it bidirectional, you have to add separate listeners for View events (like UITextField's editingChanged event) to sync back to the ViewModel—doubling your code and complexity.
Lack of lifecycle management: Unlike reactive frameworks that automatically handle subscriptions when objects are deallocated, KVO leaves you to manage all that manually, which is error-prone.

Short answer: No, don't put network logic directly in ViewModels. Here's why:

Single Responsibility Principle: ViewModels should focus on business logic and data transformation for the View. Network requests are a separate concern—they belong in a dedicated network layer (like a NetworkManager or Repository class).
Testability: If your ViewModel makes network calls directly, unit testing becomes a nightmare. You can't easily mock network responses to test different scenarios (success, failure, slow loading). By abstracting network logic into a protocol-based layer, you can inject mock implementations during testing.
Maintainability: If you need to switch network libraries (say, from Alamofire to URLSession) or update API endpoints, you only have to change the network layer—no need to touch every ViewModel that uses network calls.
Memory safety: ViewModels tied to network requests can easily cause memory leaks if the request outlives the ViewModel (e.g., the user navigates away before the request finishes). A dedicated network layer can manage request lifecycles more effectively.

内容的提问来源于stack exchange，提问作者Abhishek