在架构一个应用时，我们要建立模型，说得土一点就是建表，然后设定对这些表的各种可能操作。比如建一个 students 表，允许关联班级、导师，然后定义增删改查的操作，别搞出漏洞或者脏数据……这些事情完成，我们就实现了“领域模型”或者说“业务逻辑”（domain logic/business logic）。
但我们没有办法根据“需求”直接架构这些 Model。需求是多变的，甚至是感性的、碎片化的。而“Model”需要实打实地对应一个面向对象编程意义上的“对象”，追求单一性、里氏可替换、接口分离、开闭原则……一堆原则。
在现实中，我们不可能对“需求”使用“单一性”原则。用户打开一个知乎用户页就想看到他赞过的帖子他发表的回答；打开一篇网易新闻就想看脑残评论；打开一本文艺作品就想聆听习总在文艺座谈会上的讲话……如果把各种需求都塞到模型里，会产生大量冗余和重复的代码。
此外，对象之间天然不擅长走“工作流”，所以涉及“提交了 A 然后进入 B 页面”这种应用层面的流程需求，也很难用 Model 对象表达。
何况，需求之间也是存在“继承”的，比如一个网站的一大波页面都需要展示用户的登录信息和头像。这种数据如果你不想在 V 里面直接读 Model 的话，就只有靠 C 之间的继承来传递了。
如果一个应用同时有网站、移动 APP 和 API 接口就更容易理解了，Model 在不同应用之间应当是可以复用的，因为它走的是“业务逻辑”。
所以，我们不妨把 C 理解为“用户需求的一种抽象”。除了负责倾听用户，还负责给用户所有他需要的数据（这有些接近 ViewModel 的概念了）。这部分东西，其实也被称为“应用逻辑”（application logic）。
如果应用是个 RESTFul 的 API，那可能几乎没有 C，因为它的“用户”非常“理性”（同理，题主的例子需求是既简单又单一的“查库”，够理性，C 也没啥用）。但对于 RSS，C 可能又是必要的，但依然几乎没有 V。对于报表应用， CMS，SNS，管理后台……不同形态的应用，MVC 的情况会是天差地别。
另外：
虽然题主觉得“对 V 比较理解”。但 View 可能恰恰是 Web 程序最难说清楚的地方。
按上面对 MVC 的定义，M 和 C 的分野在业务逻辑（domain logic/business logic）和应用逻辑（application logic），而 View 仅仅是视图。
但在 Web 领域里已经没那么简单，由于前端越来越多地承担了应用逻辑的功能（毕竟用户输入都是绑定在 DOM 上的），所以承担“用户和系统之间连接”的更多是 View。这时 View 其实是“控件”而非“视图”了
金城在线专注网站、软件、APP、微信公众平台、小程序、抖音、头条等开发推广，如果您有这方面的需求或者不同的观点，欢迎联系交流。
