兩篇文章讀後感, 關於數據庫, 關於 MVC, 也關於 React

時間  2019-12-05
標籤 文章 讀後感 關於 數據庫 mvc react 欄目 SQL 简体版
原文   原文鏈接

兩篇文章

今天看了兩篇文章, 我以爲對個人影響會很大, 固然, 都是 React 相關的:html

一篇是 Martin Kleppmann 在 Strangeloop 2014 大會上的演講, 有視頻, 也有文字版, 關於數據庫:前端

Turning the database inside-out with Apache Samza
http://www.confluent.io/blog/turning-the-database-inside-out-with-apac...react

另外一篇是 Christian Alfoni 關於 Flux 的文章, 從 Twitter 上看到的, 關於 MVC 架構:webpack

Why we are doing MVC and FLUX wrong
http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MV...
https://www.youtube.com/watch?v=xCIv4-Q2dtA
http://www.christianalfoni.com/todomvc/#/git

來源

前面一篇是在 Redux 的文檔上看到的, 這文檔上有很多我關心的技術:
http://gaearon.github.io/redux/index.htmlgithub

Redux 的做者最近在 Twitter 上很是活躍, 老是在發各類 Redux 相關的消息
個人感受是 Redux 一出來, React 社區跟函數式編程, 跟將來, 的距離又拉進了一步, 一大步
包括 Clojure, Elm, PureScript 在 Twitter 上也很是地活躍... 固然也由於我關注多了這些人
而後我就經常在想, 函數式編程是真的在復興了對吧, 處處都出現了?web

關於數據庫

第一篇文章很難懂, 還好圖片多, 大體的意思就是從新思考一下數據庫
經常使用的數據庫都在基於上世紀的硬件條件設計的, 受到各類限制
若是咱們從新思考一下數據庫的應用, 應該怎麼考慮設計新的方案?數據庫

而後做者梳理了一下數據庫應用當中的幾個重要的點:apache

  • Replication 數據庫同步
  • Secondary indexing 輔助索引
  • Cache 緩存
  • Materialized views 物化視圖
  • We first discussed replication, i.e. keeping a copy of the same data on multiple machines. It generally works very well, so we’ll give it a green smiley. There are some operational quirks with some databases, and some of the tooling is a bit weird, but on the whole it’s mature, well-understood, and well-supported.
  • Similarly, secondary indexing works very well. You can build a secondary index concurrently with processing write queries, and the database somehow manages to do this in a transactionally consistent way.
  • On the other hand, application-level caching is a complete mess. Red frowny face.
  • And materialized views are so-so: the idea is good, but the way they’re implemented is not what you’d want from a modern application development platform. Maintaining the materialized view puts additional load on the database, while actually the whole point of a cache is to reduce load on the database!

實際開發的感覺而言, 前二者在數據庫內部實現很高效, 也不須要太多操心
Cache 相對來講就是一團亂麻的實現, 很是難管理
Materialized views 還不錯, 但是不適合編程, 靈活度低, 不能作太多事情編程

那麼做者想, 若是反過來, 把數據庫同步機制做爲數據庫設計的核心, 可以改善?
數據庫內部經過 Logical log 的形式, 將全部的數據保存下來, 做爲同步的手法
這裏說的是 Apache Kafka, 我彷佛記得 MongoDB, Redux, Docker, Nix 都有相似的作法
這裏的 Log 有點像 Flux 當中的 Action, 隨着時間就造成了 Stream, 用於同步數據

做者後來更加延伸一步, 以爲從數據庫到屏幕像素, 整個都是數據同步的一個過程
好比說數據庫的一些查詢結果, 至關於 Tables 的 Materialized views, 這樣一層抽象
那麼, 緩存, HTML DOM, 界面像素, 其實就是後面緊跟的一層層抽象
編寫應用而言, 若是整個是 Reactive 的, 後面跟着前面自動更新, 那將是很是高效的
考慮一下, HTML 是後端渲染的, 若是數據庫更新了, HTML 自動局部更新多好

這樣就須要引入 Stream 的機制了. 只不過, 前端的實現一般是發佈/訂閱模式
如今的 Meteor 是個特別知名的例子. Meteor 用 MongoDB 的同步機制的話可能還更像


這篇文章指出相似的方案已經有不少人在貢獻, 在開發新的工具來實現了
而特別讓我在乎的是, 整套思路至少在驗證我用 Cumulo 探索的方案至少出發點很不錯
實際上 Datomic, Redux 這些我在關注的技術, 也是朝着相似的方向前進的
有不小的可能, 將來咱們開發應用的方式, 總體是就是依照這套辦法作下去

關於 MVC

另外一篇文章是在講 MVC 和 Flux 的問題, 最後拋出本身基於 React 寫的 Cerebral
從文章的章節標題能夠看到具體的脈絡,
MVC 在前端遇到什麼問題, Flux 怎麼改進, 還能怎麼改進:

Traditional MVC
Application state
State in traditional MVC

When we moved to the frontend

  • The router is not a controller
  • The view layer bypassed the controller layer
  • No concept of a single state store
  • State in the view layer

What FLUX improved

  • Fixing the problem
  • A single state store
  • A controller with middleware
  • The views talk to the controller
  • Just do the routing

So what benefits do I really get?
Summary

後端而言, 各個 Part 之間隔離很是明顯, MVC 都有各自的程序和語言來抽象
在前端, 全部東西忽然聚在了一塊兒, 催生出特別多原來沒有的作法, 也面臨各類問題

  1. Multiple views
  2. State also inside views
  3. Multiple models
  4. We bypass the view controller model flow
  5. The router is no longer the only entry point for state change

Flux 對問題作了一些糾正, 避免了狀態分散在 View 當中的情況, 跟 MVC 更加貼近
然而其中一些 Part 的用法, 依然存在着問題:

  1. The FLUX architecture uses multiple models (stores). With traditional MVC you only have one model, your database. Multiple stores quickly causes problems when a dispatch needs to reach more than one store and especially if one store needs to know about state in an other
  2. There is no concept of middleware like in a traditional controller. This quickly introduced the concept of action creators. They are much like a single middleware that is responsible for doing everything needed related to a request from the view layer, often doing multiple dispatches to the stores
  3. When the view layer wants to get some state they still do it directly from the model layer, making unnecessary complex dependencies in the views

做者也提出了具體的解決方案, 最主要的是數據和狀態要統一到 Model 當中:

  1. We should have one model in our model layer
  2. All our state should be contained inside the model layer
  3. We should have one controller in our controller layer
  4. The view layer can only communicate with the controller layer
  5. Use a router that does not control the view layer

實際上最終做者獲得的就是一個跟 Elm 相似的, State 所有集中的幾個方案
同時, 全部的操做也能夠被收集, 跟 Elm 同樣, 能夠用於重演和調試
這裏的 Action 跟上面文章說的 Logical log 在思路上也很是類似
也很少說什麼, 我整體上認爲這是整個 React 社區將來的方向了

Big Picture

梳理一下 Time Travelling Debugger 開發的歷程, 挺讓人感概
早在函數式編程理論方面的研究我不熟悉就展開了
但實際上函數式編程, 不可變數據, 幾乎是這一套方案得以實行的基礎
由於有了統一的 State, 纔可以用一個調試工具重演整個狀態
而這些工具的進展, 我印象比較深的有這樣一些時間點:

好多年了 Bret Victor 展現的方法, 咱們平常的開發當中還沒用上 好在主體的功能, 隨着 React 社區兩年來各類事情, 好像也就一步之遙了...

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程