透过现象看本质: 常见的前端架构风格和案例
所谓软件架构风格,是指描述某个特定应用领域中系统组织方式的惯用模式。架构风格定义一个词汇表和一组约束,词汇表中包含一些组件及连接器,约束则指出系统如何将构建和连接器组合起来。软件架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将系统中的各个模块和子系统有机的结合为一个完整的系统。 没多少人能记住上面的定义,需要注意的是本文不是专业讨论系统架构的文章,笔者也还没到那个水平. 所以暂时没必要纠结于什么是架构模式、什么是架构风格。在这里尚且把它们都当成一个系统架构上的套路, 所谓的套路就是一些通用的、可复用的,用于应对某类问题的方式方法. 可以理解为类似“设计模式”的东西,只是解决问题的层次不一样。 透过现象看本质,本文将带你领略前端领域一些流行技术栈背后的架构思想。直接进入正题吧 文章大纲
分层风格 没有什么问题是分层解决不了,如果解决不了, 就再加一层 —— 鲁迅不不,原话是: Any problem in computer science can be solved by anther layer of indirection. 分层架构是最常见的软件架构,你要不知道用什么架构,或者不知道怎么解决问题,那就尝试加多一层。 一个分层系统是按照层次来组织的,每一层为在其之上的层提供服务,并且使用在其之下的层所提供的服务. 分层通常可以解决什么问题?
关注点分离之后,软件的结构会变得容易理解和开发, 每一层可以被复用, 容易被测试, 其他层的接口通过模拟解决. 但是分层架构,也不是全是优点,分层的抽象可能会丢失部分效率和灵活性, 比如编程语言就有'层次'(此例可能不太严谨),语言抽象的层次越高,一般运行效率可能会有所衰减: 分层架构在软件领域的案例实在太多太多了,咱讲讲前端的一些'分层'案例: Virtual DOM 前端石器时代,我们页面交互和渲染,是通过服务端渲染或者直接操作DOM实现的, 有点像C/C++这类系统编程语言手动操纵内存. 那时候JQuery很火: 后来随着软硬件性能越来越好、Web应用也越来越复杂,前端开发者的生产力也要跟上,类似JQuery这种命令式的编程方式无疑是比较低效的. 尽管手动操作 DOM 可能可以达到更高的性能和灵活性,但是这样对大部分开发者来说太低效了,我们是可以接受牺牲一点性能换取更高的开发效率的. 怎么解决,再加一层吧,后来React就搞了一层VirtualDOM。我们可以声明式、组合式地构建一颗对象树, 然后交由React将它映射到DOM: 所以说 VirtualDOM 更大的意义在于开发方式的转变: 声明式、 数据驱动, 让开发者不需要关心 DOM 的操作细节(属性操作、事件绑定、DOM 节点变更),换句话说应用的开发方式变成了view=f(state), 这对生产力的解放是有很大推动作用的; 另外有了VirtualDOM这一层抽象层,使得多平台渲染成为可能。 当然VirtualDOM或者React,不是唯一,也不是第一个这样的解决方案。其他前端框架,例如Vue、Angular基本都是这样一个发展历程。 上面说了,分层不是银弹。我们通过ReactNative可以开发跨平台的移动应用,但是众所周知,它运行效率或者灵活性暂时是无法与原生应用比拟的。 Taro Taro 和React一样也采用分层架构风格,只不过他们解决的问题是相反的。React加上一个分层,可以渲染到不同的视图形态;而Taro则是为了统一多样的视图形态: 国内现如今市面上端的形态多种多样,Web、React-Native、微信小程序…… 针对不同的端去编写多套代码的成本非常高,这种需求催生了Taro这类框架的诞生. 使用 Taro,我们可以只书写一套代码, 通过编译工具可以输出到不同的端: 一开始VirtualDOM和DOM的关系比较暧昧,两者是耦合在一起的。后面有人想,我们有了VirtualDOM这个抽象层,那应该能多搞点别的,比如渲染到移动端原生组件、PDF、Canvas、终端UI等等。 后来VirtualDOM进行了更彻底的分层,有着这个抽象层我们可以将VirtualDOM映射到更多类似应用场景: (编辑:ASP站长网) |