目录
“MVC”，即 Model（模型），View（视图），Controller（控制器）。
如何设计一个程序的结构，这是一门专门的学问，叫做”架构模式”（architectural pattern），属于编程的方法论。MVC 模式就是架构模式的一种。
一、 前言
首先，作为一名合格的程序猿，我们在写代码的时候都应该追求美。比如在敲每一行代码的时候，都应该注重代码规范，写出一份看得舒服，让别人也看得懂的代码，这样也能提高效率；比如在设计代码的时候，应该追求的是我怎样才能写出一个好的架构（App 架构类似于现代建筑的脚手架或者是地基，一旦确定，剩下的工作就是在现成的 App 里添砖加瓦），让我的代码模块化，分工明确，从而提高我的工作效率。
总结一下什么是好的架构：高内聚，低耦合。 代码均摊，易于扩展，具有易用性。
可以说，代码规范，架构模式，设计模式是检验一个程序猿水平的重要参考。
但是，我们创建一个控件，设置这个控件的样子，设置这个控件的交互方法，展示这个控件，都需要一定的代码量，控件少的时候还好，看得过去，但是控件一多，像下面这个 App 的界面，各种控件就多起来了，这个时候如果还把他们都堆在一个 ViewController 里面就不合适了，要改 bug，要添加控件就会变得非常麻烦。
而 MVC 架构，就是用来解决这些问题的。
二、 MVC 简单介绍
MVC 模式的基本思想：将应用程序分成三个部分，使它们各自负责不同的功能。MVC 是一种软件架构模式，它的目的是将应用程序的数据、用户界面和控制逻辑分离开来，以便各个部分可以独立地演变和修改。
- M：Model（模型）负责处理数据，以及处理部分的业务逻辑
通俗来说，就是你的程序是什么，就是你的程序将要实现的功能，或者是它所能干的事情。也就是微信消息列表里的人名字，信息内容，头像，是否屏蔽该人的消息等等数据，可以认为，Model 里面装满了这个程序的各种数据，它负责处理数据、以及处理部分的业务逻辑。
- V：View（视图）负责数据的展示和事件捕捉
通俗来说，在屏幕上你所看到的，这里有一个 UITableView，TableView 里面有 UILabel，UIImageView，你在屏幕上看到的组件，都可以归类为 View。
- C：Controller / ViewController / VC（控制器）负责协调 Model 和 View，处理大部分逻辑
它将数据从 Model 层传送到 View 层并展示出来，同时将 View 层的交互传到 Model 层以改变数据。大部分的逻辑操作（点击 Button 就是一种逻辑）都应该交由 VC 完成。（有少部分的逻辑处理交由 Model 完成，这是下文中我要提到的胖 Model 和瘦 Model）
通俗来说，就是如何使你的模型呈现给用户，比如让 View 上呈现 Model 的数据，就是 Controller 的工作。所以你可以把 Controller 看成是连接 Model 和 View 的桥梁。
用户点击 View–> 视图响应事件 —> 通过代理传递事件到 Controller–> 发起网络请求更新 Model—>Model 处理完数据–> 代理或通知给 Controller–> 改变视图样式–> 完成
胖 Model 和瘦 Model
我们刚刚说了 Model 有时候不但是数据源，有时候也会处理部分的业务逻辑。这种情况就是当 Model 里面有很多原始数据，但 View 希望展示的数据是经过加工的数据，那么这个加工的过程到底应该放在 VC 里面还是 Model 里面呢，来举个栗子说明：
View 想展示今天的日期，Model 拿到的原始数据是 20221124，但是 View 希望展示的数据是 2022 年 11 月 24 日。
所以不难想象，20221124这串数字需要经过一定的加工，才会变成我们想要的2022年11月24日。
但是这个加工过程应该放在哪里呢？是 VC 还是 Model 里面？
开发者们也思考过这个问题，因此产生了胖 Model （Fat Model） 和瘦 Model （Thin Model）
- 胖 Model 对应的是瘦的 VC（Skinny Controller），在 Model 中 对数据进行处理 ，让 Controller 可以直接使用经过处理后的数据。
- 瘦 Model 对应的是胖的 VC（Fat Controller），Model 中的数据 不进行任何处理或修改 ，原封不动的把服务器返回内容发送给 Controller。
还是用刚刚的栗子说明，胖 Model对应的是把这个加工过程放在 Model 里面（所以 Model 胖了），相反，瘦 Model 就是把加工过程放在 VC 里面。
三、 MVC 的问题
1. 视图控制器过于臃肿
在实际开发中，VC 常常承担过多职责倒置代码量巨大，可读性差
2. view 和 controller 的边界很模糊
这种模糊的边界使得开发者很容易弄混代码应该放置的位置，最终导致了第一条的代码臃肿问题
解决方法：
为了解决这些缺点，衍生出了许多改进的架构模式： - MVVM (Model-View-ViewModel) 核心思想： 引入一个
ViewModel层，专门负责从Model获取数据并进行处理，转换成View可以直接显示的数据。它通过数据绑定（Data Binding）机制（如 KVO、Notification、RAC 或 Combine）通知View更新。 - 优点： 极大地减轻了ViewController的负担，使其只负责视图绑定和简单的逻辑转发。ViewModel不依赖UIKit，易于测试。 - MVP (Model-View-Presenter) 核心思想：Controller/View的角色被弱化，由一个Presenter来承担绝大部分业务逻辑。View通过协议（Protocol）与Presenter通信，实现了更好的解耦。 - 优点： 视图和逻辑完全分离，可测试性极强。 - VIPER (View-Interactor-Presenter-Entity-Router) 核心思想： 将职责划分得更加细致，每个字母代表一个明确的职责模块。它更适用于超大型项目，追求极致的可测试性和模块化。 - 缺点： 引入的模板代码较多，学习曲线较陡峭，对于中小型项目可能显得 “杀鸡用牛刀”。
在接下来的项目如计算器中，我会开始尝试使用 MVC 架构。
https://juejin.cn/post/7098623916452610078?searchId=20250831221503BC226F5D134DA78BCF89
原文发布于 CSDN：【iOS】MVC 架构