两篇文章读后感, 关于数据库, 关于 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教程