有 Schema虽然从前到后都是使用 JSON，但也不用担心数据结构混乱，因为表结构和 JSON 的映射是有配置文件定义的，可以通过这个结构定义生成建表 SQL，也可以通过已有的数据库表生成这个结构定义。
基于 Servlet另起炉灶（比如 Play）无论是对做轮子还是对用轮子的人来说成本都太高了，而且 Servlet 对 HTTP 的抽象还是比较适当的，这个真没必要再弄一套，Latke 轮子实在碾不过去的地方就直接操作 Request 和 Response 吧，这个大家都会。
多种 DB支持多种数据库的 JSON 化 CRUD，要更换数据库（虽然真实世界很少发生）很方便：有数据导出/导入工具，无痛数据迁移（比如从 GAE Datastore 迁移到 MySQL）。
插件可以在不改动任何一行现有代码的前提下添加新功能，而且这个新功能是完整的（前端后端都有），可以很容易就集成到现有界面中的任何地方。
各种工具Cache、Event、Cron、IoC、i18n、HTTP client、mail、themes 已经内置，虽不敢说每个服务功能如何强大，但我敢说对大部分的应用场景已经足够使了，并且轮子本身的第三方依赖也是精挑细选的，这些工具加一起真的足够了。
性能从实现上看是 Servlet 的薄封装，理论上和直接使用 Servlet 性能差距不会太大，实际上我们也是进行过压测的，结果显示没有性能问题。
再进一步“用上 Latke 轮子后开发效率提升一大截，但还是嫌前进太慢，怎么破？” 这已经不是轮子圆不圆的问题了，这是造轮子时使用的材料问题（风火轮和我们汽车轮子一样圆吧，可实际上速度不是一个量级的，还可以当作武器，另外，这个还和使用的人有关吧）。 Java 就这样了，我们既然用了就说明我们已经接受它了，既然接受了就得忍让着点，最终忍不了就可以像王垠大神一样。不过对于我们凡人来说，比较切实可行的做法是换个编程语言，种种迹象表明，Node.js 在应用开发领域已经风生水起。
最后前面说了一大推来证明 Latke 是圆的，要是你不相信，请看下《Latke 快速上手指南》，里面有个 demo；要是你还不相信，就亲自试用吧 ;-p
参考
|
