Web 技术研究所

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

试试多维度的 Web 架构?

  我以前总是怕把代码搞成一坨,于是就尽可能地把可用的维度降低,这样就算开发者想些出奇奇怪怪的代码都难。比如使用 Angular 的时候,Angular 自带了 module 系统,虽然设计地非常烂,但我还是用了。因为害怕引入一套新的 module 系统会把事情搞砸。
  也许这话听起来很高端,但其实一点都不高端。像 Angular 这样自己的一套体系,我们就称它为一个维度。假如一个项目使用了 Angular,并且又推荐使用 requirejs 来加载模块,那么这就变成两个维度在开发。
  为何这么说呢?比如在只有 Angular 的时候,两个 Controller 之间的数据共享可能会通过一个 Service 来实现。或者说这是最佳实践,因为其它数据共享方案都有坑,都属于黑魔法。那么在只有 Angular 的体系下,当我们看到两个 Controller 在共享数据,自然就会联想到是有个 Service 在背后支持。有时候这是别无选择的,就像数轴上的 1 和 3 这两个点在实数这个维度下要用一条连续的线连接起来就必定会经过 2 这个点。当我们把维度扩展的复平面的时候,从 1 到 3 的连线就可以有无数条,而且未必需要经过 2 这个点。或者说,两个 Controller 共享数据可以直接通过 requirejs 来解决,不用依赖 Angular 自带的 Service。
  突然从原来的唯一路径变成无数条路径就是个问题。我以前怕把代码搞成一坨就是希望大家对同一个问题都使用唯一的解决方案,这样可以让代码维护起来更加方便。首先要明确的是,降低维度的做法确实很有效!但在实践过程中也暴露出了一些问题,某些本来很简单的东西由于框架的限制而变得非常繁琐。比如 DOM 操作在原来 jQuery 时代都是直接上的,到 Angular 中不建议 Controller 直接操作 DOM,于是开发者在需要操作 DOM 时就需要特意去写个 Directive,哪怕只是很简单的东西。
  React 的组件之间传输数据也得通过 props 一层层地传(虽然可以用 context,但是这东西太难用了,估计后面 API 会有调整)。如果我们有另一个维度的数据传输通道,比如全局的 pub/sub,这些麻烦的问题就都能解决。
  我觉得是否应该降低维度这件事是值得反思的,是否可以使用多维度开发,并且通过其它方式来解决代码变成一坨的问题?
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^