我對先後端數據模型和數據流的理解

編程源於生活

編程是什麼？咱們寫的業務代碼是什麼？它和咱們的現實世界有什麼關係？ 我以前一直在想這個問題。如今我以爲，代碼是對現實世界的一種抽象，源於生活又高於生活，他經過數據的方式來抽象現實世界的一些過程，多是一次商業活動，多是一次運動的過程等等。 數據是最基礎的東西，數據來源於自動採集的和用戶輸入的。咱們作業務開發首先要創建起你所關心的業務對應的數據模型，而後基於這個數據模型作各類數據的管理以及分析等各類之上的操做，讓這個業務過程以及數據自己產生商業價值。

數據的流動

數據模型設計好了，他落實到物理存儲多是各類數據庫，關係型、對象型、文檔型、圖型等等，根據數據模型的特色選擇不一樣的方式來存儲。以後服務端會連接到數據庫，而後在服務端創建起對應的數據模型，好比用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等。

固然後端到了必定的規模，會作分佈式、微服務等等，數據庫也會分庫分表，這是相似的思路。好比安卓經過多進程的方式來拆分複雜度等。

總之，創建起數據模型，和先後端對應的架構。以後就是用戶的各類交互，產生的各類數據在整個系統之間流動了。