首页 ›存档› 技术 › 查看内容

理想的应用框架

2018-3-30 13:00 |来自: 互联网 351 0

摘要: 背景在过去对框架的设计中，我收到过的最有用的建议是：“不要一开始就根据现有的技术去整合和改进。而是先搞清楚你觉得最理想的框架应该是怎样的，再根据现在的技术去评估，的确实现不了时再妥协。这样才能做出真 ...

背景

在过去对框架的设计中，我收到过的最有用的建议是：“不要一开始就根据现有的技术去整合和改进。而是先搞清楚你觉得最理想的框架应该是怎样的，再根据现在的技术去评估，的确实现不了时再妥协。这样才能做出真正有意义的框架。”
在这篇文章里，就让我们按照这样一条建议来探索一下现在的 web 框架最终可以进化成的样子，你绝对会被惊艳到。

前端，还是从前端说起。前端目前的现状是，随着早期的 Backbone，近期的 Angular、React 等框架的兴起，前端在 模块化、组件化 两个方向上已经形成了一定的行业共识。在此基础上，React 的 FLUX、Relay 则是进一步的对前端应用架构的探索。这些技术在目前国内的大公司、大团队内部实际上都落地得非常好，因为很容易和公司内部已有的后端技术栈结合。而且这些纯前端框架的配套技术方案一般比较成熟，例如在支付宝确定使用 React，其实有一部分原因是它兼容 IE8，并且有服务器端渲染方案来加速首屏。

相比之下，像 Meteor 这类从前到后包办的框架就较难落地。虽然能极大地提高开发效率，整体架构非常先进，但架构的每一个层级往往不容易达到行业内的顶尖标准。特别是在服务器端，对大公司来说，通常都有适合自己业务的服务器集群、数据库方案，并且经受过考验。因此当一个团队一上手就要做面向十万级、甚至百万级用户的产品时，是不太愿意冒风险去尝试的。反而是个人开发者、创业型的团队会愿意去用，因为确实能在短时间内高效地开发出可用的产品出来。包括像 Leancloud 提出的这类型的服务，也是非常受欢迎的。

这种现状，就是理想和现实的一个争论。Meteor 的方式能满足我对开发效率的理想，而团队已有的技术方案能保障稳定。能否整合其中的优势，不妨让我们进一步来细化一下对框架的希望：

- 有强大的前后端一致的数据模型层
- 代码可以可以复用。例如我有一个 User 模型，当我创建一个新的 user 时，user 上的字段验证等方法是前后端通用的，由框架自动帮我区别前后端环境。
- 数据模型和前端框架没有耦合，但可以轻松结合。这样在前端渲染型的框架进一步升级时，不影响我的业务逻辑代码。
- 由数据模型层提供自动的数据更新机制。例如我在前端要获取 id 为 1 的用户，并且如果服务器端数据有更新的话，就自动帮我更新，不需要我自己去实现轮询。我希望的代码写法是:

var user = new User({id:1});
user.pull();
user.watch();

实际上，Meteor已经能实现绝大部分上述功能。但这不是软文。我要强调两点我不希望的：

- 我不希望这个数据模型层去包含业务逻辑，也就是我创建的user对象，我不希望它提供 login、logout 等 api。
- 我也不希望数据模型层自动和任何ORM框架绑定，提供任何 SQL 或 NoSQL 的数据支持。

看到这两点你可能心中大打问号，这两点不正是高效的精髓吗？前后端逻辑复用，屏蔽数据库细节。别急，让我们重新用“理想的方式”来思考一下“逻辑”和“数据持久化”这两件事。

数据与逻辑

我们以这样一个问题开头：任何一个应用，我们的代码最少能少到什么程度？

这算半个哲学问题。任何人想一想都会得到同一个答案：最少也就少到和应用本身的描述一一对应而已了。什么是应用描述？或者说什么是应用？我们会这样描述一个博客：“用户可以登录、退出。用户登录后可以发表文章。发表文章时可以添加相应的标签。”

抽象一下描述，答案很简单：数据，和逻辑。

如果你在一个流程要求严格的公司，应用描述就是prd或系分文档。应用的数据就是数据字典，应用的逻辑就是流程图的总和：

流程图

那么代码最少能怎么写呢？数据很简单，参照数据字典，我们来用一种即使是产品经理都能掌握的伪码来写：

//描述字段User : {
name : string
}

Post : {
title : string,
content : text
}

Tag : {
name : string
}//描述关系User -[created]-

声明：文章版权归原作者所有部分文章转自互联网如有侵权请联系 [邮箱地址] 删除

路过

雷人

握手

鲜花

鸡蛋

收藏分享邀请

上一篇：ApacheKafka：下一代分布式消息系统下一篇：Airbnb如何设计机器学习模型

理想的应用框架

背景

数据与逻辑

相关分类