前言
大家应该都知道 MVC 架构思路。
而 MVCS, 从名字就可以看出, 是基于 MVC 衍生出来的一套架构。
从概念上来说, 它拆分的部分是 Model 层, 拆出来一个 Service。这个 Service 专门负责数据存取。
但从实际操作的角度上讲, 它拆开的是 Controller。
这算是 Skinny Model 的一种方案, Skinny Model 只是专门用于表达数据, 然后存储、处理数据都交给外面的来做。
MVC 使用的前提是, 它假设了你是 Skinny Model, 同时数据的存储和处理都在 Controller 去做。
所以对应到 MVCS, 它在一开始就是拆分的 Controller。
因为 Controller 做了数据存储的事情, 就会变得非常庞大, 那么就把 Controller 专门负责存取数据的那部分抽离出来, 交给另一个对象去做, 这个对象就是 Service。
这么调整之后, 整个结构也就变成了真正意义上的 MVCS。
关于 Fat Model 和 Skinny Model
好多年前, 国外业界曾经对此有过非常激烈的讨论, 主题就是 Fat model, Skinny controller。
现在关于这方面的讨论已经不多了 (何止不多, 貌似都快没了, 我都没百度到相关资讯)
Fat Model
Fat Model 包含了部分弱业务逻辑, 也可以理解为 Skinny Controller。
Fat Model 要达到的目的是, Controller 从 Fat Model 这里拿到数据之后, 不用额外做操作或者只要做非常少的操作, 就能够将数据直接应用在 View 上。
众所周知, 强业务变动的可能性要比弱业务大得多, 弱业务相对稳定, 所以将弱业务塞进 Model 是没问题得。
另一方面, 弱业务重复出现得频率要大于强业务, 对复用性得要求更高, 如果这部分业务写到 Controller, 类似得代码会撒得到处都是, 一旦弱业务有修改, 这将会是一场灾难。
如果塞进 Model 里, 改一处很多地方就能跟着改, 就能避免这场灾难。
然而其缺点就在于, Fat Model 相对比较难移植, 虽然只是包含弱业务, 但好歹也是业务, 迁移得时候很容易拔出萝卜带出泥。
另外一点, MVC 的架构思想更加倾向于 Model 是一个 Layer, 而不是一个 Object, 不应该把一个 Layer 应该做的事情交给一个 Object 去做。
最后一点, 软件是会成长的, Fat Model 很可能会随着软件的成长越来越 Fat, 最终难以维护。
Skinny Model
Skinny Model 只负责业务数据的表达, 所有业务无论强弱一律扔到 Controller, 从而形成了 Fat Controller。
Skinny Model 要达到的目的是, 尽一切可能去编写细粒度 Model, 然后配套各种 Helper 类或方法来对弱业务做抽象, 强业务依旧扔给 Controller。
由于 Skinny Model 跟业务完全无关, 它的数据可以交给任何一个能处理它数据的 Helper 或者其他对象来完成业务。
在代码迁移的时候独立性很强, 很少会出现拔出萝卜带出泥的情况。
另外, 由于 Skinny Model 只是数据表达, 对它进行维护基本上是零成本, 软件膨胀再厉害, Skinny Model 也不会大到哪里去。
缺点就在于, Helper 这种做法不见得很好。另外, 由于 Model 的操作会出现在各种地方, Skinny Model 在一定程度上违背了 DRY (Don’t Repeat Yourself) 的思路, Controller 仍然不可避免在一定程度上出现代码膨胀。
总结
因此, MVCS 是基于 Skinny Model / Skinny Controller 的一种架构思路。
把原本 Fat Model / Fat Controller 中的业务代码抽象成了 Service, 在一定程度上降低了 Model / Controller 的压力。
本文由
Oscaner
创作, 采用
知识共享署名4.0
国际许可协议进行许可
本站文章除注明转载/出处外, 均为本站原创或翻译, 转载前请务必署名
