用户
 找回密码
 入住 CI 中国社区
搜索
查看: 4348|回复: 8
收起左侧

[Web] 讨论下 CodeIgniter 的缺点?

[复制链接]
发表于 2013-11-1 00:40:47 | 显示全部楼层 |阅读模式
本帖最后由 Hick 于 2013-11-1 00:45 编辑

个人对 CodeIgniter 虽然一直印象比较好,但是缺乏实际使用经验。几年前 1.5 版的时候捣腾学习了下,如今杀回来看到 2.x 基本上还是跟之前类似,保持着小巧的身段,惹人可爱。 打算一边做点东西一边深入学习下,希望能定制,改掉一些不大爽的东西 --- 于是乎 CI 为了尽可能支持多的 php 版本做了很多牺牲,感觉没有太多的必要。  

还不大熟,先列下几个小点,以及想法:

- 到处是诸如 $this-> 的调用,写起来比较麻烦,可以考虑改成一般的类调用,利用 __autoload__ 自动加载类, 还不大清楚 CI 本身的加载方式除了版本的考虑是不是有性能方面的原因?

- 整合外部的库和工具默认支持不大好, 比如 laravel 的 blade 个人比较喜欢; composer 这样的新兴包管理整合还得捣腾----虽然都有找到教程。

- migration 这样的东西个人其实不是特别喜欢,不过可能有人喜欢? 这在某些人眼里可能也算缺点?

- 1.6 版的时候就把 scaffolding 去掉了,不过个人觉得针对常规的数据库管理,确实可以有一套类似机制生成默认的管理程序。这点学习 django 有出路和使用场景,加强下安全,限于后台使用就好。


边做东西边总结了下,发在我的 blog 里:  CodeIgniter基础使用和实现原理 (地址  http://blog.hickwu.com/HickMap%EF%BC%9ACodeIgniter%E5%9F%BA%E7%A1%80%E4%BD%BF%E7%94%A8%E5%92%8C%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86    ) ,还没弄完,最近一段时间里会持续更新。 尤其欢迎大家指点和提建议。



{:soso_e181:}





评分

参与人数 1威望 +5 收起 理由
Hex + 5 赞一个!

查看全部评分

 楼主| 发表于 2013-11-1 00:44:37 | 显示全部楼层
限制可真够严的, 竟然不支持链接... {:soso_e127:}  

点评

Hex
感谢支持CI中国,由于目前垃圾贴泛滥,所以新注册用户不能使用链接,请努力发帖升级用户组即可解决。  发表于 2013-11-1 09:54
 楼主| 发表于 2013-11-1 10:17:50 | 显示全部楼层
Hick 发表于 2013-11-1 00:44
限制可真够严的, 竟然不支持链接...

{:soso_e113:}
发表于 2013-11-1 16:36:44 | 显示全部楼层
“功能太欠缺” 或者“支持不太好”这样的的缺点也可以看作是CI的优点:集中精力做好基础,解决真正的问题,至于功能可以根据需要由社区去拓展
发表于 2013-11-1 16:39:59 | 显示全部楼层
Ahgigu 发表于 2013-11-1 16:36
“功能太欠缺” 或者“支持不太好”这样的的缺点也可以看作是CI的优点:集中精力做好基础,解决真正的问题 ...

@Hex 发表于 2009-9-25 10:12:46


其实 CI 并不是非常严格的 MVC,所以给开发者留得余地很大,CI 的目标就是让开发者按照自己的方式来编程。




 楼主| 发表于 2013-11-2 10:05:32 | 显示全部楼层
Ahgigu 发表于 2013-11-1 16:36
“功能太欠缺” 或者“支持不太好”这样的的缺点也可以看作是CI的优点:集中精力做好基础,解决真正的问题 ...

是必须“集中精力做好基础”, 问题是什么算“基础”。
不管是 php 本身还是 php框架都在不断的进化发展,基础的定义必须变化。

composer 这样的东西至少理念上相当现代化,不喜欢框架核心就自带很多 composer 包的如 laravel 这样的,功能够强,但是臃肿。但是兼容并包 composer 这样的机制,可以作为“基础”的一部分了。
 楼主| 发表于 2013-11-2 10:10:00 | 显示全部楼层
Ahgigu 发表于 2013-11-1 16:39
@Hex 发表于 2009-9-25 10:12:46

说这是 CI 的目标之一没错。但是这绝不是首要目标,否则的话别整什么 CI 框架,全都从 php 起家干起来好了。

框架本身提供灵活的底层建筑,利用周边生态是很重要的。

个人对 CI 的认识水平有限,有些可能确实还没理解原来的用意,至少目前为止非常不喜欢什么都以 $this 开头的调用,认为改造这个并不难,不妨碍上面提到的任何目标。
发表于 2013-11-6 17:38:43 | 显示全部楼层
Hick 发表于 2013-11-2 10:10
说这是 CI 的目标之一没错。但是这绝不是首要目标,否则的话别整什么 CI 框架,全都从 php 起家干起来好 ...

我觉得随着时间“功能”会慢慢演化成为“基础”。
个人对“功能和基础”的看法,是从Java那体验来的。
无论从那些年流行的SSH(Struts, Spring, Hibernate)还是后来到hTC开发的Android应用,体验的结果是:
Java“基础”太差,以至于为了完成日常任务都需要用构建的“功能”去完成,此话怎讲?
比如数据库的操作,Java需要JDBC-ODBC这些java包,去完成像连接数据库这种基础的任务,
要知道写java代码不就是为了完成定制的“功能”才让人可以定制的去发挥,让我们的应用不断的一层一层的构建在不断变成“基础”的“功能”上吗?
我体验到PHP的好处就是“把这些基础固化在语言里”。

回到CI的功能是不是太少的话题上,窃以为CI的美妙在于“少”,因为PHP的本身特性或者历史原因,构建php应用却又不是靠语言本身就可以避免或者完成
现在看来是“基础”的问题或者任务,而且这些问题获任务并不是那么容易就可以解决,所以CI适时的定位在一些看似功能很弱的基础上,以优雅的方式满足着许多如我一般执着于简单的开发者。
打个比方,不久前看过关于一个女子保镖训练的新闻,也许CI就是这些美妙的保护着我们安全的尤物。

“有限的资源专注于基础,把自由留给广大的社区的力量。”
 楼主| 发表于 2013-11-9 11:54:51 | 显示全部楼层
扯得有点远, 只想说: 即使是在数据库操作这层,php的所谓基础操作已经在不断的演化了,PDO 在几年前是没有的事,这不妨碍其基础性。

自带 composer 包肯定不是基础,但是本身提供使用 composer 这样的包机制,是一种很有价值的基础能力。不限制社区力量发挥的自由,也不需要什么特别的资源去做这种基础支持---不提供用户也可以折腾出来,和官方提供支持是俩码事。 如果拿一天有一种比 composer 更牛的能力,就应该收罗其机制,同时毫不犹豫的把 composer 交给用户去自由发挥。

本版积分规则