MVC（Model-View-Controller）
核心作用：分离数据逻辑、界面展示和用户交互
iOS应用：UIKit的基石（如UIViewController管理视图）
代码实现：
// Model
struct User {
var name: String
}
// View (Storyboard/XIB构建)
// Controller
class ProfileVC: UIViewController {
var user: User!
@IBOutlet weak var nameLabel: UILabel!
override func viewDidLoad() {
super.viewDidLoad()
nameLabel.text = user.name
}
}
优势：职责清晰；陷阱：Controller易膨胀（需结合MVVM优化）
单例模式（Singleton）
适用场景：全局唯一资源管理（如网络监控、数据库）
Apple示例：UserDefaults.standard、FileManager.default
安全实现：
class NetworkManager {
static let shared = NetworkManager()
private init() {} // 防止外部实例化
func fetchData() { ... }
}
// 调用：NetworkManager.shared.fetchData()
注意事项：避免滥用导致内存泄漏（优先依赖注入）
观察者模式（Observer）
动态响应：数据变化自动通知依赖对象
iOS实现：
- NotificationCenter：跨模块通信
// 发送通知 NotificationCenter.default.post(name: .dataUpdated, object: nil)
// 接收通知
NotificationCenter.default.addObserver(
self,
selector: #selector(handleUpdate),
name: .dataUpdated,
object: nil
)
KVO：键值监听（Swift推荐使用`didSet`属性观察器替代）
---
### 四、委托模式（Delegate）
交互解耦：对象将任务委托给协议实现方
经典案例：`UITableViewDelegate`处理点击事件
自定义委托：
```swift
protocol DataLoaderDelegate: AnyObject {
func didReceiveData(_ data: [String])
}
class DataLoader {
weak var delegate: DataLoaderDelegate?
func load() {
let data = ["A", "B", "C"]
delegate?.didReceiveData(data)
}
}
// 使用方遵守协议
class ViewController: DataLoaderDelegate {
func didReceiveData(_ data: [String]) {
print("Received: \(data)")
}
}工厂模式（Factory）
动态创建：统一接口生成不同类型对象
应用场景：根据条件创建UI组件
enum Theme { case light, dark }
class ButtonFactory {
static func createButton(theme: Theme) -> UIButton {
switch theme {
case .light:
return LightThemeButton()
case .dark:
return DarkThemeButton()
}
}
}
// 使用
let button = ButtonFactory.createButton(theme: .dark)
优势：隔离创建逻辑，支持快速扩展新类型
适配器模式（Adapter）
兼容转换：让不兼容接口协同工作
实战案例：整合第三方SDK
// 现有支付接口
protocol PaymentService {
func processPayment(amount: Double)
}
// 第三方支付适配器
class StripeAdapter: PaymentService {
private let stripe = StripeSDK()
func processPayment(amount: Double) {
stripe.charge(amount) // 转换调用逻辑
}
}
设计模式选择策略
- 避免教条主义：MVC不适合复杂页面时改用MVVM
- 性能权衡：观察者模式在大型项目中优先选用Combine框架
- Swift特性结合：
- 用
struct实现不可变Model - 通过
extension遵守协议保持代码整洁
- 用
- 单元测试：委托模式比单例更易测试（依赖注入）
经验提示：过度设计比缺乏设计更危险，初期可先用MVC快速迭代，在模块复杂度上升时逐步引入其他模式重构。
互动话题：你在项目中遇到过哪些设计模式误用？或者尝试过用SwiftUI结合Redux模式？分享你的实战经验，评论区一起探讨iOS架构的进化方向！
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/ios%e5%bc%80%e5%8f%91mvc%e4%b8%8emvvm%e8%ae%be%e8%ae%a1%e6%a8%a1%e5%bc%8f%ef%bc%8c%e5%93%aa%e7%a7%8d%e6%9b%b4%e5%a5%bd%ef%bc%9f%e6%9e%b6%e6%9e%84%e9%80%89%e6%8b%a9%e6%8c%87%e5%8d%97/
评论列表（6条）
看完这篇文章，真心觉得说到点上了！我刚开始做iOS开发时，完全不懂设计模式，直接套用MVC，结果搞出个大坑。那是个小社交app项目，ViewController越写越大，像个垃圾场一样塞满了数据处理、UI更新和网络请求。每次加新功能都得翻来覆去改它，测试起来简直噩梦，一个地方错整个崩溃，调试到半夜都找不出原因，真是头疼死了。 后来项目升级，我咬牙试了MVVM，把业务逻辑全丢进ViewModel，View只剩显示逻辑。虽然上手有点学不会，但代码瞬间清爽了，改bug快多了，团队协作也顺溜。说实话，没有哪个绝对好，但MVVM在复杂应用里确实更省心，尤其避免ViewController膨胀。建议大家别像我一样死守MVC，灵活选架构，少走弯路啊！
这篇文章对iOS开发中MVC和MVVM的对比写得挺清楚的，特别是点明了MVC在UIKit里的核心地位，比如UIViewController的角色，让新手也能快速理解设计模式的基本区别。作为实用指南，它帮开发者梳理了选择思路，挺实用的。不过，值得深入探讨的是，MVVM虽然被捧为解决视图逻辑分离的利器，但它的管理复杂度和学习曲线会不会让小型团队吃不消？现实中许多简单应用用MVC反而更顺手，避免过度设计。我个人经验是，架构选型得看项目大小——复杂业务选MVVM省心，但快速迭代时MVC更直接。希望文章能多聊聊团队磨合和性能影响这些实战细节，那会更有启发。总之，没有最好的模式，只有最适合的场景。
作为一个iOS新手，看了文章还是有点迷糊，MVC和MVVM在实际项目中到底哪个更容易上手？希望大神能分享点经验，谢谢啦！
这篇文章写得非常好，内容丰富，观点清晰，让我受益匪浅。特别是关于优势的部分，分析得很到位，
这篇文章写得非常好，内容丰富，观点清晰，让我受益匪浅。特别是关于优势的部分，分析得很到位，
@happy633boy：这篇文章写得非常好，内容丰富，观点清晰，让我受益匪浅。特别是关于优势的部分，分析得很到位，