我对前后端数据模型和数据流的理解

编程是什么？我们写的业务代码是什么？它和我们的现实世界有什么关系？ 我之前一直在想这个问题。现在我觉得，代码是对现实世界的一种抽象，源于生活又高于生活，他通过数据的方式来抽象现实世界的一些过程，可能是一次商业活动，可能是一次运动的过程等等。 数据是最基础的东西，数据来源于自动采集的和用户输入的。我们做业务开发首先要建立起你所关心的业务对应的数据模型，然后基于这个数据模型做各种数据的管理以及分析等各种之上的操作，让这个业务过程以及数据本身产生商业价值。 ###数据的流动 数据模型设计好了，他落实到物理存储可能是各种数据库，关系型、对象型、文档型、图型等等，根据数据模型的特点选择不同的方式来存储。之后服务端会链接到数据库，然后在服务端建立起对应的数据模型，比如用 java 的orm框架hibernate，mybatis等，然后对数据模型的各种操作就是业务的过程，各种业务逻辑在这里来做，这是model层，暴露的是对数据模型各种操作的接口。之后接口暴露出去，通过http、websocket、rpc、消息队列等各种方式，这一层算是服务端的view层，view层和model层之间是多对多的关系，之间复杂的调用关系一般单独一层，叫做controller层，这一层一般很薄，不含任何业务逻辑。 之前的前端属于服务端view层的一部分，没有任何的数据，只是纯粹渲染，有了ajax以后，慢慢发展到现在的单页应用，前端需要在本地维护一套数据模型，然后同时也要暴露基于这个数据模型的各种接口，之后业务逻辑单独封装一层，提供给view层的组件调用。

各层次的数据模型和业务逻辑

从大方面来看，分为 数据库、 服务端、前端（客户端）。 涉及到3个数据模型和对应的管理数据模型的接口，他们各有特点：

1. 数据库：

数据库只有数据模型和数据，没有任何逻辑，向外暴露了管理数据模型的接口，就是 sql 或者是类似 mongodb 的js引擎等。

2：服务端：

服务端主要是管理数据库中的数据，完成各种业务逻辑，同时提供数据给客户端。服务端的数据模型是同步的数据库中的，通过一定的映射关系建立对应的数据模型，然后提供对数据模型操作的接口，完成各种业务逻辑，最终通过各种协议（http、ws、rpc、消息队列等）暴露出去。

3. 前端（客户端）：

前端也需要维护一个本地的数据模型，然后通过和服务端的接口通信来保持数据模型的同步，同时提供了对数据模型操作的接口。比如用redux来管理state，那么对应的reducer就是操作他的接口，之后基于这些管理数据模型的接口来完成一些业务逻辑，同时提供给组件来渲染，组件属于view层，数据模型、操作数据模型的接口、业务逻辑的service属于model层，之间多对多的映射关系其实就是组件里事件绑定和各种方法调用，这样的话组件属于view + controller（因为实现了mvvm，所以controller更薄了）。

数据库的数据模型、后端的数据模型、前端的数据模型，这些都应该是后者依赖前者的，所以需要通信和同步的过程，同时为了优化一些性能，会做一些缓存，当然实时性要求高的不会做缓存。 除了三个层次一致的数据模型之外，也有一些不需要同步的状态，比如前端的一些ui的状态，比如服务端的一些上下文的数据等。 除此以外，前端的view层触及到了人，会涉及到一些用户心理学，设计学，会涉及到交互和设计方面的东西，这是另一门学问。

总结

总体来看的话， 其实最两端的是 数据库的数据模型 和 ui。 然后中间每一层都有独立维护的数据模型， 以及基于这些模型各自的架构和接口，当然之间需要同步，同步的方式就是通过 socket，sql，http等。

当然后端到了一定的规模，会做分布式、微服务等等，数据库也会分库分表，这是类似的思路。比如安卓通过多进程的方式来拆分复杂度等。

总之，建立起数据模型，和前后端对应的架构。之后就是用户的各种交互，产生的各种数据在整个系统之间流动了。