目录
"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