Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

MV* 是个错误的方向

  早期的 Web 都是由后端渲染的,所以都是 MVC 走起的,因为 MVC 的概念就是一个数据源、一个可编程的模板引擎以及一个路由系统。像 PHP 这样本身就是基于模板的语言就是原生的 MVC。后来为了把 V 层丢给切图匠去写,把里面的逻辑抽到了 C 层中,于是就变成了 MVP。
  再后来,「切图匠」这个职业转换为了「前端」,于是把 MVP 这一套也搬到了前端。如今,前端的交互越来越泛滥,动态数据的需求越来越高,静态的 MVP 已经无法再满足需求,于是出现了 MVVM 这样自带数据绑定的东西。
  仔细想想,好像 MV* 这套东西最初是从后端开始的。为什么前端非要 MV* 不可呢?我觉得 MV* 是一个错误的方向。
  为什么 View 要单独抽取成一层?当初这么做的目的是打算把 View 交给切图匠,然而现在开发人员的组织架构上已经没有这个职业了(也许有些公司依然保留,但迟早会干掉的,因为现代 Web 的复杂交互不是切图匠可以驾驭的)。如果我们把组件的粒度分到足够细的话,每个组件直接就视为一个整体,再去分个 Model 和 View 反而把事情搞复杂,把性能搞渣。我觉得 View 可以并到组件上,没有单独提取出来的必要。而 Model 确实是需要的,它以 Service 的概念存在,一个 Service 可以为多个组件提供并共享数据。
  也许是单页应用崛起的太晚的缘故吧?我觉得现在的前端框架把路由放到了一个很尴尬的位置。我觉得路由就是 Controller,它应该是单独的一层。在 Controller 中决定了哪些组件该被放到页面上。而且它应该是整个架构的顶层,所有行为从它开始!
  最终应该是 Controller Service Component 这样的东西(但我不想把它称为 CSC)。
  那么 MV* 的概念就完全没用了么?也不是,我觉得对于复杂的交互和展示的实现,MV* 的模式还是很不错的。我只是觉得它不该直接用于项目的前端架构而已。在组件内部如果存在复杂的交互和展现,依然可以使用 MV* 来局部实现。
  最后值得一提的是,这里的「组件」是包含 HTML 和 CSS 的。也就是说 HTML 和 CSS 都属于「组件」的一部分。而且组件是建议黑盒实现,只提供接口,不把无用的东西暴露出去,也不该受到外部环境的影响。这个过程在目前的浏览器的兼容程度上是有坑的,就算是 Web Components 应该也只是勉强可以实现的程度。如果直接想使用它,可能会遇到无法定义文件结构的情况。所以我打算过段时间造一套「超 Web 前端框架(基于预处理)」,可能就不再是传统的 HTML + CSS + JS 的 Web 开发模式了。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^