对symfony框架的一些深入研究
2009-03-03 18:57
351 查看
在两个项目中应用symfony的不同版本后,有很多感触。symfony框架的初衷是很美好的,在1.0的版本中这个初衷已经基本实现。但是其向更高方向的发展,不得不说是一个不实用的精品。很多程序员玩OOP玩的走火入魔,企图什么都封装,什么都自动生成。这像是在追求放之四海皆准的真理。
闲扯的话就不说了,先与大家讨论一下symfony两个主要版本1.0&2.0之间的区别(有不同意见的尽管拍砖,有想补充的可以补充)。
1.symfony1.0拥有的基本功能就不说了。若能够很好的应用脚手架的话,将节省很多写代码的时间。可以生成form的Module,还可以根据configuration的yml,可以实现validate,authentication,包含js&css之类的,以及后台的自动生成。symfony2.0的版本在1.0上做的最完美的就属form表单的封装和配置,以及更加完美的后台自动生成。这可能是两个版本中最大的改进。
2.两个版本中一些细节性的问题:
symfony2.0将所有的验证都封装到form表单里,并且删除了sf_request中的hasError等函数,所以在2.0中无法使用form_error.如果采用其form形式,则不用担心验证的问题。如果不采用或者无法采用其form形式,那只有自己写验证,用setFlash/getFlash来解决了。但是这样的话,除了简单的可以用yml验证的之外,复杂点的验证都需要自己写,那简直就是噩梦。
另外,symfony2.0中lib的module里面的基本类里,已经没有doSelectRS()这个函数,这是一件很痛苦的事情。如果你所开发的项目中有很多表有关联关系,并且你不可能将所有的关联关系都加载在数据库文件里,这个时候,实现取自多张表的一些信息的一个list的时候,你很有可能会看到几百条sql。如果遇到这种情况,可以查看一下Peer下面的所有的doselect的函数。尤其是doSelectJoin**这个函数,在数据库的表中添加了关联信息,则查出的结果很庞大。所以,symfony2.0中应用Propel来解决多个表的关联时很麻烦。doSelect函数只往它所在的module的class里面赋值,不会把关联表里搜出来的也添加进来。结果就是,你addJoin后doSelect了,除了这个类的基本信息,其他的什么都没有查出来。要想得到正确的值,要么你自己重写doSelect的函数,要么你用它的doSelectJoin**之类的函数。总之,个人认为Propel的东西太多的规则,应用面不广泛。也许,我们可以试着使用Doctrine。
至于,symfony中完美的form封装和Admin Generator,对大点的复杂点的项目可能就不太实用了。除非在设计数据库时,充分考虑了symfony框架的特性。并且,能够完美配置form封装和Admin Generator的也是“独孤求败”级别的高手了。
最后,需要提到的就是配置以及写自用的helper。symfony的配置文件种类比较多,自己心中一定要有个分类,在书写任何一个界面时,尽量首先想到用yml文件来配置。而写自用的helper也是一个非常必要的思想,有重用可能的、或者共用的函数尽量写成helper。这就是“不要重复自己”的原则。
闲扯的话就不说了,先与大家讨论一下symfony两个主要版本1.0&2.0之间的区别(有不同意见的尽管拍砖,有想补充的可以补充)。
1.symfony1.0拥有的基本功能就不说了。若能够很好的应用脚手架的话,将节省很多写代码的时间。可以生成form的Module,还可以根据configuration的yml,可以实现validate,authentication,包含js&css之类的,以及后台的自动生成。symfony2.0的版本在1.0上做的最完美的就属form表单的封装和配置,以及更加完美的后台自动生成。这可能是两个版本中最大的改进。
2.两个版本中一些细节性的问题:
symfony2.0将所有的验证都封装到form表单里,并且删除了sf_request中的hasError等函数,所以在2.0中无法使用form_error.如果采用其form形式,则不用担心验证的问题。如果不采用或者无法采用其form形式,那只有自己写验证,用setFlash/getFlash来解决了。但是这样的话,除了简单的可以用yml验证的之外,复杂点的验证都需要自己写,那简直就是噩梦。
另外,symfony2.0中lib的module里面的基本类里,已经没有doSelectRS()这个函数,这是一件很痛苦的事情。如果你所开发的项目中有很多表有关联关系,并且你不可能将所有的关联关系都加载在数据库文件里,这个时候,实现取自多张表的一些信息的一个list的时候,你很有可能会看到几百条sql。如果遇到这种情况,可以查看一下Peer下面的所有的doselect的函数。尤其是doSelectJoin**这个函数,在数据库的表中添加了关联信息,则查出的结果很庞大。所以,symfony2.0中应用Propel来解决多个表的关联时很麻烦。doSelect函数只往它所在的module的class里面赋值,不会把关联表里搜出来的也添加进来。结果就是,你addJoin后doSelect了,除了这个类的基本信息,其他的什么都没有查出来。要想得到正确的值,要么你自己重写doSelect的函数,要么你用它的doSelectJoin**之类的函数。总之,个人认为Propel的东西太多的规则,应用面不广泛。也许,我们可以试着使用Doctrine。
至于,symfony中完美的form封装和Admin Generator,对大点的复杂点的项目可能就不太实用了。除非在设计数据库时,充分考虑了symfony框架的特性。并且,能够完美配置form封装和Admin Generator的也是“独孤求败”级别的高手了。
最后,需要提到的就是配置以及写自用的helper。symfony的配置文件种类比较多,自己心中一定要有个分类,在书写任何一个界面时,尽量首先想到用yml文件来配置。而写自用的helper也是一个非常必要的思想,有重用可能的、或者共用的函数尽量写成helper。这就是“不要重复自己”的原则。
相关文章推荐
- 正在研究一些Javascript的框架
- hadoop深入研究:(十三)——序列化框架
- 记一些需要深入研究的东西
- 最近研究DONET的开发框架,在网上收集了一些资源。写道博客上已备忘
- 深入研究Netty框架之Channel和Unsafe详解
- 大家都知道,木头一直都没有在大的游戏公司待过,没见识也没经历过优秀的项目。最近想研究一些开源的Unity3D框架,开拓一下自己的思维。 优先入坑的是Entitas框架,本系列教程基于0.42.3版本。
- springMVC框架 深入研究(上)
- symfony框架下服务器(linux-Ubuntu)部署的一些常见问题[汇总中]
- Collection 集合框架深入研究
- biti_rainy回滚段的深入研究--(一些有用的语句)
- checkbox复选框的一些深入研究与理解
- CI框架深入篇(2)一些基础的我之不知道的标准格式
- hadoop深入研究:(十三)——序列化框架
- 深入研究Netty框架之ByteBuf功能原理及源码分析
- 关于一些前端js框架的源码研究
- 从零开始开发IoC依赖注入框架 -- containerx (深入研究Spring源码)
- 关于一些前端js框架的源码研究
- symfony框架下服务器(Windows)部署的一些常见问题[汇总中]
- 深入研究Netty框架之ChannelHandler和ChannelPipeline