M =>Model, V =>View, C =>Controller
我习惯性写法是业务逻辑能在 Model 中写就在 Model 中,然后 C 调用 M。 大家是怎么理解这玩意的。
1
itenyh 2018-07-26 11:00:46 +08:00
Model 是存放数据的地方,并不负责处理数据;如果是 MVC 模式,数据处理应该放在 C 中,这会导致 C 变得越来越大,为了解决这个问题,出现了 MVVM。
|
2
zoffy 2018-07-26 11:08:47 +08:00
我觉得 V 现在没什么存在感了,倒不如说是 MBC 模式,B 代表 Business 层
|
3
rbe 2018-07-26 11:36:00 +08:00
前后端分离的话,View 层确实没什么存在感了。
Model 层不应该有太多处理数据的逻辑,组装、处理数据应该放在 Controller 中的。如果你觉得重复性的东西比较多,可以抽象出一个 Service 层,然后 Controller 去调用各种 Service。 Node 的 Egg.js 框架就是这么做的。 |
4
saulshao 2018-07-26 17:24:22 +08:00
这个东西就是一个逻辑上的概念,从历史上来看,J2EE 和 Windows DNA 这种架构也是类似的概念。
基本思想就是数据存储,计算,展示这 3 个行为应该由不同的代码模块来实现。 这些概念的目的在我看来就一个:尽可能重用代码,换个说法叫偷懒。 所以对于数据庞大的系统,就扩展数据存储部分,可能需要一些额外的代码来支持这种能力。 而对于处理逻辑复杂的系统,就应该扩展计算能力。 而类似于仪表盘,看板这种系统,就应该扩展展示层的能力。 |
5
canxden 2018-07-26 18:34:54 +08:00
因为面试的原因, 看过很多这方面的东西, 各种设计模式.
其实要说清楚这个问题, 思考过程应该是: Q1:为什么会产生设计模式, 或者说设计模式的意义是什么 A1: 统一编程方式, <这是一种对人类主观不足的补充>, 程序日渐复杂 (需求一直在加多和变化), 我不能一行看完全部代码. 如何规范我的代码哪里写什么, 或者说代码怎么写容易被他人快速理解和找到, 从而快速进行需求扩张. 遂出现统一的设计模式. 有一点要反思的就是, 这不一定最好, 但是一定能解决问题. Q2:为什么设计模式会具象到使用 MVC 模式, 或者说 MVC 到底是干嘛的 A2: 我觉得这个问题主要在"解决问题"这个需求上. 人们的需求日益增加, 产品需要快速迭代, 但是我们不能一个版本就重写一份. 如何做到快速迭代就是 MVC 的优势, 分离[数据 视图 逻辑]三部分内容, 先分化, 再细化. 找出抽象内容. 将改变制定到具体内容上. 就不赘述面向对象的三大原则了. 不同语言下的 MVC 都会进行各种改变, 但是核心还是为了不断更变的需求服务. 但是实际上并没有规范 MVC 中到底应该拥有什么, 有人贪图方便就在 V 中写网络请求(不推荐这样), V 给自己提供数据. 但是这也是解决了问题. 所以 MVC 不一定最好, 但是一定能解决问题. 其实我觉得没必要纠结 MVC 是什么, 它早已不是最好, 只是一个时代的产物, 他能解决很多问题, 但是现在已经有许多更好的解决方式了. 所以不必要纠结和规范 MVC. 因为核心需求一直在改变的话, 设计模式实际上就一直在变. |