在我最近的工作中，最让人抓狂的就是为前端开发人员设计API。我们之间的对话大致就是这样的：
我甚至没有进行进一步的争论。项目结束时会积累大量的API，这些API与经常发生变化的页面是关联在一起的，按照“设计”，只要页面改变，相应的API也要随之变化，而在此之前，我们甚至对此毫不知情，最终，由于形成因素众多且各平台之间存在些许差异，必须创建非常多的API来满足这些需求。 Sam Newman甚至将这种制度化的过程称之为BFF模式，这种模式建议为每种设备、平台当然还包含APP版本开发特定的API。Daniel Jacobson在接受InfoQ的采访时曾指出，Netflix颇为勉强地将“体验式API”与“临时API（Ephemeral API）”划上了等号。唉…… 几个月前，我开始思考是什么造成了如今的这种现象，该做些什么来应对它，这个过程使我开始质疑应用架构中最强大的理念，也就是MVC，我感受到了函数式反应型编程（reactive）的强大威力，这个过程致力于流程的简化，并试图消除我们这个行业在生产率方面的膨胀情绪。我相信你会对我的发现感兴趣的。 在每个用户界面背后，我们都在使用MVC模式，也就是模型-视图-控制器（Model-View-Controller）。MVC发明的时候，Web尚不存在，当时的软件架构充其量是胖客户端在原始网络中直接与单一数据库会话。但是，几十年之后，MVC依然在使用，持续地用于OmniChannel应用的构建。 Angular 2正式版即将发布，在这个时间节点重估MVC模式及各种MVC框架为应用架构带来的贡献意义重大。 我第一次接触到MVC是在1990年，当时NeXT刚刚发布Inte**ce Builder（让人惊讶的是，如今这款软件依然发挥着重大的作用）。当时，我们感觉Inte**ce Builder和MVC是一个很大的进步。在90年代末期，MVC模式用到了HTTP上的任务中（还记得Struts吗？），如今，就各个方面来讲，MVC是所有应用架构的基本原则。 MVC的影响十分深远，以致于React.js在介绍他们的框架时都委婉地与其划清界限：“React实现的只是MVC中视图（View）的部分”。 当我去年开始使用React的时候，我感觉它在某些地方有着明显的不同：你在某个地方修改一部分数据，不需要显式地与View和Model进行交互，整个UI就能瞬间发生变化（不仅仅是域和表格中的值）。这也就是说，我很快就对React的编程模型感到了失望，在这方面，我显然并不孤独。我分享一下Andre Medeiros的观点：
作为服务端的API设计者，我的结论是没有特别好的方式将API调用组织到React前端中，这恰恰是因为React只关注View，在它的编程模型中根本不存在控制器。 到目前为止，Facebook一直致力于在框架层面弥合这一空白。React团队起初引入了Flux模式，不过它依然令人失望，最近Dan Abramov又提倡另外一种模式，名为Redux，在一定程度上来讲，它的方向是正确的，但是在将API关联到前端方面，依然比不上我下面所介绍的方案。 Google发布过GWT、Android SDK还有Angular，你可能认为他们的工程师熟知何为最好的前端架构，但是当你阅读Angular 2设计考量的文章时，便会不以为然，即便在Google大家也达成这样的共识，他们是这样评价之前的工作成果的：
基于组件的Angular 2看起来能简单一点吗？其实并没有好多少。Angular 2的核心包本身就包含了180个语义（semantics），整个框架的语义已经接近500个，这是基于HTML5和CSS3的。谁有那么多时间学习和掌握这样的框架来构建Web应用呢？当Angular 3出现的时候，情况又该是什么样子呢？ 在使用过React并了解了Angular 2将会是什么样子之后，我感到有些沮丧：这些框架都系统性地强制我使用BFF“页面可替换模式（Screen Scraping）”模式，按照这种模式，每个服务端的API要匹配页面上的数据集，不管是输入的还是输出的。 此时，我决定“让这一切见鬼去吧”。我构建了一个Web应用，没有使用React、没有使用Angular也没有使用任何其他的MVC框架，通过这种方式，我看一下是否能够找到一种在View和底层API之间进行更好协作的方式。 就React来讲，我最喜欢的一点在于Model和View之间的关联关系。React不是基于模板的，View本身没有办法请求数据（我们只能将数据传递给View），看起来，针对这一点进行探索是一个很好的方向。 如果看得足够长远的话，你会发现React唯一的目的就是将View分解为一系列（纯粹的）函数和JSX语法：
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
