Phalcon的问题就是有时候我想调试到Phalcon代码里就无能为力了

总之，或许我花半个月时间能领会到L的精髓，但我肯定无法忍受要教会我的每个同事那么困难的东西。

至于phalcon，PHP有什么IDE能支持点一下追踪到C的代码里？ 能支持我也还要再去用21天精通C，别开玩笑了，拿买安卓看各种跑分的思路选PHP框架？

Yii好不好使我也不知道，但总之L和phalcon对我来说是被排除掉了

你这只是单纯从性能上来比较而已，事实上性能没有想象中那么重要，不然php都没有存活的必要了。

嗯，是，但rails是一整套类似Yii的完整的内建模块，而laravel则是一堆开发物件拼凑起来的，用起来不像Yii现有可用，还得找，composer，下载，等。Yii的小物件之类的很鸡肋我同意，但说重，是因为Yii已经全部给你摆这了，你没看到laravel的分量：）

Yii不需要你去追踪，你只需打开gii，点下一步，全给你生成了…………

嗯，我个人不喜欢自动生成代码，我认为如果框架的业务代码繁杂到需要另一个生成器来生成不是什么好信号。

当然如果只是拿来玩，快速搞个playground上手没啥问题，但真格的写项目我觉得还是应该由开发人员一行行写，了解每行代码的意义。

可能ORM或者protobuf这种由数据结构定义生成数据容器类的生成器还好，其他controller乃至完整app的生成我都觉得只能是玩具

80%的项目里的80%的业务都是增删改查，利用生成来解决这些，然后把主要精力来写核心业务代码上面，这样不挺好的么？

+1, 不知道那些可以利用代码来自动生成的CRUD和HTML代码有什么意义需要了解的

用 php 谁还特别在乎这点? 问题得看场景.

Yii 挺好的, 框架层面没明显缺陷, 看会不会用了

如果框架要求业务代码写很多没意义的代码，那我觉得是框架本身的convention没有做到位。写代码生成器可能会麻痹关于这种bad smell的警觉。 某些语言／运行时／框架new一个空白project 4位数的生成代码我真心不觉得是好事

可能是我接触的业务大多数都不在64%里面吧

yii2的优势在于框架帮你实现了大部分常用功能，是真正只从实战角度来设计的php框架，怎么让开发更高效就怎么来，所以你会看到，生成一个数据列表居然这么简单，几行代码就搞定了，分页、汇总都有，配套的js代码也都帮你生成。你甚至不用关心UI，默认也帮你提供了。CRUD这些都变得异常简单，以前烦的要死的表单验证，大部分只需要声明一下就可以。

社区也非常活跃，可以看看他们的主站，扩展区跟wiki两个地方，每天都有内容更新。

不过手册跟不上是yii最大的问题，框架本身提供的功能实在太多，真心写不过来，很多功能都是阅读源代码后才知道原来框架已经实现了。

PS：才发现评论不能修改，只能跟后面了。

另外Laravel的性能比yii差的多，很多国外框架评测都有。

可以这么说：性能比yii好的，没他功能完善。功能比他完善的，性能差他很多。

然后说说phalcon，这是个非常优秀的php框架，很早以前就开始关注了，不得不说这个框架非常牛逼，一举解决了PHP框架给人性能差劲的映像（请不要再拿诸入CI之类的框架来说事了，完全看不出这种只是稍微提升了一点点开发效率的框架有哪里值得推崇了，除了他那非常不错的手册，大家要明白，现在是21世纪14年代，不是那遥远的20世纪90年代，老爷爷辈的该退场就要退场）性能超牛逼不说，功能也非常强大，ORM、Form、DI等等，现代化框架该有的功能基本都有了，手册也写的很详细，基本上你看完就可以动手开发，唯一的问题就是由于是用C写的，导致扩展起来比较麻烦，所以更新速度有点慢。期待正在开发的2.0能够解决。

至于yii2跟phalcon到底该怎么选，前几天跟朋友就此进行过激烈争吵，得出结论：yii2是精装房(框架本身提供的各种功能)，你买来往里填点家具就可以住的很舒适(在此基础上快速开发产品)，看哪不爽可以自己敲掉重新装(框架本身可扩展性好，绝大部分组件可以使用自定义的替换)，项目时间短，不想太折腾，需要做的快性能又还凑合，就选他。phalcon是毛坯房，给你的时候什么都没有(缺少一些可提升开发效率的系统组件)，你可以根据自己喜好进行装修(在框架的基础上扩展功能)，项目时间足够，爱折腾，同时性能是关键指标，就选他。

routing可以自己写的好不好？

DI，你确认你离了DI不能活？

算不算能力问题。。实在不行稍微跟踪下也要不了半小时呀。alais

命名空间完全没问题。IDE也能解决。只需要搜索一下github google 都能解决呀。

或许是能力不行吧，但我觉得框架能写到找个实现代码都得要求有些什么能力，那这个框架至少不适合工业生产

根据我玩node的经验，确实存在这个风险，所以在挑选三方组件的时候要留意测试用力的完整性和覆盖程度，以及安装次数／github star等参数综合评估

不过内部组件用composer分解是提高维护性的，把以前大量的自写lib 分门别类搞成package，减小单个repo代码体积，依赖更清晰，也更容易写测试和维护

从alpha开始用Yii2，感觉比Yii1好用多了，主要是有了namespace，可以不用像之前为类名头疼了，ActiveRecord支持连贯输入后比之前用CDbCre那个类方便多了，现在是beta阶段，根据我的使用情况来看，已经可以用在开发环境里了。

看过手册，没有具体使用过，不是很喜欢那种大杂烩式的框架。。。

孩子你受ci影响太深了，酱紫不好……

哥, 看到你的名字是v神, 忍不住回复你一下:

你没找到 View::make() 的代码, 难道你不觉得奇怪, 并且好奇它是怎么做到的, 这样做有什么好处吗? 看在它在 github 上 1 万多个 stars, 超 Yii 几条街的份上, 花点时间研究一下总没坏处的.

Laravel 里面很多代码都写得很漂亮, 用到的思想也是前卫的, 而且里面的组件可以单独拿出来用. 像 就写得相当好, 如果你有写单元测试的话, 相信你是能感受得到的.

9神。你难道看不出我是顶laravel的么，除了性能偏低以外其他都好。我是找的到的好吧。是mcfog。。

有计划了联系下，我们在招人， 坐标上海，行业电商。

我很佩服能在PHP的螺蛳壳里做出facade这样“动态”的机制，但单元测试不是只有这一条路可走，在我看来这种做法和试图在JS里搞类型安全的typescript类似，属于强行和语言风格作对。 反正如果我接手的项目如果已经是Laravel那我会认真学，但让我自己从头起的项目用Laravel我还是敬谢不敏的。我承认Laravel思想前卫，机制先进，在PHP的语法框架里做出了新意，但我觉得选PHP框架不是选新意或者思想，如果单人solo，或是10个Laravel的作者一起开发项目，可能确实手到擒来，但10个一般人想用好Laravel这样的框架难度太大了。

个人感觉框架的使用还是取决于需求以及业务场景来选择 至于性能问题 绝对不在php这个层面 生产效率远远大于所谓的性能效率

谢谢，不过这个已经收录了，官网上的音标和单词 view 英式发音一样，所以就用的那个

Ubuntu 找了很久，感觉都和主流读音差别有点大，最后采用的维基百科的读音，不知你有官方读音的地址吗

都可以 不过第一种是都 sei 扣

阿贾克斯问题不大啊。标准读音是诶贾克斯，差不多的话不影响理解。日文里是读アジャックス的。

我找了下，作者读 拍 phone，似乎国内是读拍森吧，这就很尴尬了

666 不过我本意不是找读错的，是找不知道怎么读的

有个哥们把 FEC 读出的的调调我听不懂。好像类似 FADE(FAKE)？

我到现在也没确定是该读“密要”还是“密月”

是“密钥”还是“秘钥”

如果用中文来表示的话更接近坚 go。。。