前端的架构设计

前端的架构是什么？

https://www.zhihu.com/question/26646855/answer/68503768

前端项目大概会经历以下这些阶段：

整体渲染

结构行为表现分离

隔离逻辑单元

插件

模块

前端MVC/MVVM

组件

先进的想法并不会区分前后端，而是被用到了所有适用的地方。

一个软件项目，随着待解决业务问题的发展，和问题复杂度的不同，会存在以下几个阶段，

具体解决方案

共用代码

功能独立的工具

架构模式

5. 领域特定语言（DSL）

常用软件架构

常用的软件架构主要有：

**MVC (Model-View-Controller)**： Model-View-Controller 架构模式用来构建 Web 应用。该架构有三个部分: 模型(Model)、视图(View) 和控制器(Controller)。
**MVVM (Model-View-View Model)**： MVVM 架构是一种简化 MVC 架构的一种模式。它使用同样的三个部分：模型(Model)、视图(View)和 View Model。
**REST (Representational State Transfer)**： Representational State Transfer（REST）是一套架构设计原则，它可以用来构建 web 上的应用程序。 REST是基于 HTTP 协议的，并定义一系列规则，用来处理客户端和服务器之间的交互。
Event-Driven Architecture： Event-Driven Architecture是一种面向事件的架构，可以将特定的操作流程表示出来。这是一种较新的软件架构，可以用来跟踪数据并处理事件。

前端架构类型

我们的3D框架用到的架构：

OOP：封装、继承、多态，因为场景中有不同的节点类型，每个类型的表现会不一样；OOP中业务问题被抽象成类，接口模板，数据和行为被统一封装在对象内部，作为程序的基本组成单元，但是我们目前没封装好，数据和行为在外部也会被操控和修改。

基于消息驱动的状态切换

图元抽象

基于消息驱动的UI/3D主体通信

响应式编程(store)

事件驱动：Flux

消息驱动：

基于状态机：Redux

数据流：React

编程范式/编程模型

方案设计时，就应该包含编程范式的选型这一步。

命令式编程/过程式编程

C语言

面向对象编程

声明式编程

Spring Boot基于注解的方式就是声明式编程

Spring框架依赖AOP和IoC编程思想降低了开发者对底层逻辑业务细节的了解程度。例如在Spring Boot中，通过@Transactional注解可以声明一个方法具备事务性的操作，当异常发生时，事务会自动回滚，保证业务逻辑的正常和数据一致性。发生在@Transactional注解背后的实现细节，开发者可以不去关心。

Vue组件？

很多标记性语言，如HTML、XML、XSLT，就遵循声明式编程范式

函数式编程

响应式编程

响应式编程(Reactive Programming)：React

包括：面向对象的响应式编程（OORP），函数响应式编程（FRP）等

函数式编程：

设计思路

https://www.zhihu.com/question/587090539/answer/2920684245

面向对象的理解≈组合和继承的理解≈业务拆分和转发

把所有的流程都用对象描述出来，然后画一个有向无环图。接着就是对象分层和细化。把不变的和变的分开。

当然，箭头的图标分可视化时段和非可视化时段，那么可视化时段可以理解为上台时段，非可视化则分上台前和下台后。台上时段，就相当于一个传送带，传送带还分多个区块，区块还会附加控制器，输入判断控制器就是一种控制器。。。

场景论

这个似乎是SceneGraph?

时间线理论

生命周期？

传送带理论

柯里化？流程管理？

分形(Fractal)

自相似性

ECharts的Element + Group的设计就是分形的应用。

面向对象的实体设计，也是分形思想的一种应用。分形分得多细，决定了你的对象设计粒度有多细。

3D中，是通过矩阵来解决分形后子组件的坐标描述问题的。

这在我们的组件开发中也适用：用父状态描述/管理子组件的状态(递归计算出子组件的状态)。

组件的设计，是一棵倒置的树。

参考资料

什么是响应式编程？

In computing, reactive programming is a programming paradigm oriented around data flows and the propagation of change.

事件驱动机制跟消息驱动机制相比，有哪些优劣的地方？

事件模式耦合高，同模块内好用；消息模式耦合低，跨模块好用。事件模式集成其它语言比较繁琐，消息模式集成其他语言比较轻松。事件是侵入式设计，霸占你的主循环；消息是非侵入式设计，将主循环该怎样设计的自由留给用户。如果你在设计一个东西举棋不定，那么你可以参考win32的GetMessage，本身就是一个藕合度极低的接口，又足够自由，接口任何语言都很方便，具体应用场景再在其基础上封装成事件并不是难事，接口耦合较低，即便哪天事件框架调整，修改外层即可，不会伤经动骨。而如果直接实现成事件，那就完全反过来了。

作者：韦易笑
链接：https://www.zhihu.com/question/30393750/answer/48037230
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。