关于 MVC 的理解

[Edwards]

M =>Model， V =>View， C =>Controller

我习惯性写法是业务逻辑能在 Model 中写就在 Model 中，然后 C 调用 M。 大家是怎么理解这玩意的。

[itenyh]

Model 是存放数据的地方，并不负责处理数据；如果是 MVC 模式，数据处理应该放在 C 中，这会导致 C 变得越来越大，为了解决这个问题，出现了 MVVM。

[zoffy]

我觉得 V 现在没什么存在感了，倒不如说是 MBC 模式，B 代表 Business 层

[rbe]

前后端分离的话，View 层确实没什么存在感了。
Model 层不应该有太多处理数据的逻辑，组装、处理数据应该放在 Controller 中的。如果你觉得重复性的东西比较多，可以抽象出一个 Service 层，然后 Controller 去调用各种 Service。
Node 的 Egg.js 框架就是这么做的。

[saulshao]

这个东西就是一个逻辑上的概念，从历史上来看，J2EE 和 Windows DNA 这种架构也是类似的概念。
基本思想就是数据存储，计算，展示这 3 个行为应该由不同的代码模块来实现。
这些概念的目的在我看来就一个：尽可能重用代码，换个说法叫偷懒。
所以对于数据庞大的系统，就扩展数据存储部分，可能需要一些额外的代码来支持这种能力。
而对于处理逻辑复杂的系统，就应该扩展计算能力。
而类似于仪表盘，看板这种系统，就应该扩展展示层的能力。

[canxden]

因为面试的原因, 看过很多这方面的东西, 各种设计模式.

其实要说清楚这个问题, 思考过程应该是:
Q1:为什么会产生设计模式, 或者说设计模式的意义是什么
A1: 统一编程方式, <这是一种对人类主观不足的补充>, 程序日渐复杂 (需求一直在加多和变化), 我不能一行看完全部代码. 如何规范我的代码哪里写什么, 或者说代码怎么写容易被他人快速理解和找到, 从而快速进行需求扩张. 遂出现统一的设计模式. 有一点要反思的就是, 这不一定最好, 但是一定能解决问题.

Q2:为什么设计模式会具象到使用 MVC 模式, 或者说 MVC 到底是干嘛的
A2:
我觉得这个问题主要在"解决问题"这个需求上. 人们的需求日益增加, 产品需要快速迭代, 但是我们不能一个版本就重写一份.
如何做到快速迭代就是 MVC 的优势, 分离[数据 视图 逻辑]三部分内容, 先分化, 再细化. 找出抽象内容. 将改变制定到具体内容上. 就不赘述面向对象的三大原则了.
不同语言下的 MVC 都会进行各种改变, 但是核心还是为了不断更变的需求服务.
但是实际上并没有规范 MVC 中到底应该拥有什么, 有人贪图方便就在 V 中写网络请求(不推荐这样), V 给自己提供数据. 但是这也是解决了问题. 所以 MVC 不一定最好, 但是一定能解决问题.

其实我觉得没必要纠结 MVC 是什么, 它早已不是最好, 只是一个时代的产物, 他能解决很多问题, 但是现在已经有许多更好的解决方式了. 所以不必要纠结和规范 MVC. 因为核心需求一直在改变的话, 设计模式实际上就一直在变.

[Edwards]

@all 感谢各位指点