程序员心中最佳的框架组合.docx

在过去对框架的设计中，我收到过的最有用的建议是：“不要一开始就根据现有的技术去整合和改进。而是先搞清楚你觉得最理想的框架应该是怎样的，再根据现在的技术去评估，的确实现不了时再妥协。这样才能做出真正有意义的框架。”在这篇文章里，就让我们按照这样一条建议来探索一下现在的 web 框架最终可以进化成的样子，你绝对会被惊艳到。 前端，还是从前端说起。前端目前的现状是，随着早期的 Backbone，近期的 Angular、React 等框架的兴起，前端在?模块化、组件化?两个方向上已经形成了一定的行业共识。在此基础上，React 的 FLUX、Relay 则是进一步的对前端应用架构的探索。这些技术在目前国内的大公司、大团队内部实际上都落地得非常好，因为很容易和公司内部已有的后端技术栈结合。而且这些纯前端框架的配套技术方案一般比较成熟，例如在支付宝确定使用 React，其实有一部分原因是它兼容 IE8，并且有服务器端渲染方案来加速首屏。 相比之下，像 Meteor 这类从前到后包办的框架就较难落地。虽然能极大地提高开发效率，整体架构非常先进，但架构的每一个层级往往不容易达到行业内的顶尖标准。特别是在服务器端，对大公司来说，通常都有适合自己业务的服务器集群、数据库方案，并且经受过考验。因此当一个团队一上手就要做面向十万级、甚至百万级用户的产品时，是不太愿意冒风险去尝试的。反而是个人开发者、创业型的团队会愿意去用，因为确实能在短时间内高效地开发出可用的产品出来。包括像 Leancloud 提出的这类型的服务，也是非常受欢迎的。 这种现状，就是理想和现实的一个争论。Meteor 的方式能满足我对开发效率的理想，而团队已有的技术方案能保障稳定。能否整合其中的优势，不妨让我们进一步来细化一下对框架的希望： - 有强大的前后端一致的数据模型层- 代码可以可以复用。例如我有一个 User 模型，当我创建一个新的 user 时，user 上的字段验证等方法是前后端通用的，由框架自动帮我区别前后端环境。- 数据模型和前端框架没有耦合，但可以轻松结合。这样在前端渲染型的框架进一步升级时，不影响我的业务逻辑代码。- 由数据模型层提供自动的数据更新机制。例如我在前端要获取 id 为 1 的用户，并且如果服务器端数据有更新的话，就自动帮我更新，不需要我自己去实现轮询。我希望的代码写法是: user = 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]- Post Post -[has]- Tag 这里为了进一步帮助读者从已有的技术思维中跳出来，我想指出这段伪码和数据库字段描述有一个很大的区别，那就是：我不关心 User 和 Post 中间的关联关系到底是在两者的字段中都创建一个字段来保存对方的id，还是建立一个中间表。我只关心我描述它时的逻辑就够了。数据描述的代码，最简也就简单到这个程度了。 那么逻辑呢？我们先用按常规方式试试？ class User{ createPost( content, tags= post = Post({content:content}) post.setTags( tags.map(tag