`
Jennycn
  • 浏览: 99244 次
  • 性别: Icon_minigender_2
  • 来自: 北京
社区版块
存档分类
最新评论

Follow your heart(109)--got the last proposal

    博客分类:
  • zend
阅读更多
today I got the last proposal. I mean , according to my deadline date on elance.

This company has some experiences on google map and realized a trip plan application before. They mentioned about Zend framework. I never heard it before.

Just searched about something about this:http://www.zendlab.com/2010/08/zend-framework-%E5%AD%A6%E4%B9%A0%E6%95%99%E7%A8%8B%E2%80%94%E2%80%94%E5%88%9D%E8%AF%86zend%E6%A1%86%E6%9E%B6/


众所周知,几年前,在众多强大且易用的脚本语言中,PHP 占据着首要位置。大多数基于 UNIX® 和 Linux® 的 Web 服务器都安装了该语言。如果您是一个程序员,您很容易获得一个主机帐户来使用该语言。Ruby 曾经风靡一时,但现在已经没有多少人使用了。如果您曾经想使用动态生成的内容来构建一个网站,但却并不确定是否要使用诸如 J2EE 之类的应用服务器,那么您就极可能使用 PHP。它快速、易学、方便,您无需学习 Perl。

  然后情况很快改变。Ruby on Rails 震惊了编程界。Ruby on Rails 是面向对象和基于模型-视图-控制器 (MVC) 的典范,它提供了一种方式来实现我们都想实现的事情,即不费任何力气地创建一个网站。当然,仍然存在两个问题。一个问题是您需要学习一门新的编程语言。不管这门语言是什么样的,这都不是一项简单的任务。另一个问题是,如果您找到一台能运行 Ruby on Rails 的主机,那是非常幸运的,而大多数情况下不可能。如果您(像我一样)拥有一个 10 年的帐户,仅因为其缺少新的编程语言,那么放弃起来会犹豫再三的。当然,您这些年来编写的所有现有的 PHP 代码也是一个问题。您真的愿意把它们全部扔掉并重新开始吗?当然不是!

  一个有进取心的 PHP 程序员需要做什么呢?那就是创建一个囊括大多数上述新优势的新框架。Zend 框架由此诞生了。

  Zend 框架提供了简洁稳定的代码,也许最为重要的是,它是在明晰的知识产权下完成的。PHP 正在企业界跑马圈地,但如果您是一家财富 500 强公司,您不会愿意冒险将模块提交给一个也许是属于其他公司知识产权的知识库。

准确地讲 Zend 框架究竟是什么呢?Zend 框架具有以下特征:

* 是基于 PHP 建立的。
* 是面向对象的。
* 使用 MVC 范例。
* 具有开放源码贡献者。
* 有贡献者负责保证他们的代码不是他人的知识产权。

  通过建立 MVC 模式,Zend 框架的目标是使编程生活更加轻松,这不仅体现在通用领域,而且对您始终想要做的具体的事情也是如此,比如访问数据库或输出 PDF 文件。(也许您一直都不输出 PDF 文件。但如果它更简单的话,我想您会去这样做的。)

Zend 框架组件包括:

Zend_Controller
此模块为应用程序提供全面的控制。它将请求转化为特定的行为并确保其执行。

Zend_Db
此模块基于 PHP 数据对象 (PDO) 并提供一种通用方式来访问数据库。

Zend_Feed
此模块使使用 RSS 和 Atom 提要变得简单。

Zend_Filter
此模块提供字符串过滤函数,如 isEmail() 和 getAlpha()。

Zend_InputFilter
对于 Zend_Filter,此模块是用来操作数组的,如表单输入。

Zend_HttpClient
此模块使您能轻易地执行 HTTP 请求。

Zend_Json
此模块使您能够轻易地将 PHP 对象转换成 JavaScript 对象符号,反之亦然。

Zend_Log
此模块提供通用日志功能。

Zend_Mail
此模块使您能够发送文本文件和多部分 MIME 电子邮件。

Zend_Mime
此模块被 Zend_Mail 用来解码 MIME 消息。

Zend_Pdf
此模块用来创建新的 PDF 文档,及加载和编辑现有文档。

Zend_Search
此模块使您能在现有文本上执行复杂搜索。例如,您可以建立一个搜索引擎,该引擎可以基于相关性或其他因素返回结果。

Zend_Service_Amazon、Zend_Service_Flickr 以及 Zend_Service_Yahoo
这些模块提供对这些 Web 服务 API 的简单访问。

Zend_View
此模块处理 MVC 模式的 “视图” 部分。

Zend_XmlRpc
此模块使您能够轻易地创建 XML-RPC 客户机。(已为将来计划好服务器功能。)
分享到:
评论
15 楼 Jennycn 2011-10-13  
nkhanxh 写道

就是矫情,一个switch case也那么啰嗦,
他看过交换机里面代码吗,不少switch case呢。

这玩意好就好在效率高,另外用一用肯定是没问题的。
什么最新的软件科学之类的,都是他以为的最新,早就有了。



呵呵,唉,看这些都把我搞晕了,不过现在慢慢也有个大致概念了.
目前为止,这个提到要用zend的是在地图上做过几个项目的,写的工作流程什么的,也看起来像模像样,就是他们建议用php的这个zend框架.

他们在pilot阶段,报价还是相对最高的 比2-3个用java的高

还有个java的,打算用java的cms + java core,还是说,java的cms上延伸出来的java core,我也没看明白:)

14 楼 nkhanxh 2011-10-12  

就是矫情,一个switch case也那么啰嗦,
他看过交换机里面代码吗,不少switch case呢。

这玩意好就好在效率高,另外用一用肯定是没问题的。
什么最新的软件科学之类的,都是他以为的最新,早就有了。

Jennycn 写道
3.
http://bardo.iteye.com/blog/666818
人说,Zend Framework的开发团队中,全是全世界最优秀的PHP程序员。我看这话说得是没有调查,也过于迷信。
     因为,Zend Framework中一样也有很多相当初级的代码。如果你不信,你可以自己找一些代码进行分析。
     我们举个简单的例子。有人说,优秀的PHP程序员,绝对不会使用switch case控制结构, 为什么?
     道理很简单,但这里不妨向大家说一下:
     1、PHP支持函数变量与对象变量,同时有强大的数组,因而能够直接形成变量与目标的映射。
     2、最新软件科学中,设计模式,代码重构,均是在不断讲解,避免使用switch case,比如,工厂模式,注册表模式,装载器模式,配置模式等。所有这些,最简单的实现方式就是不用这些模式,全能够用switch case实现。
     2、一旦使用switch case,那就证明了,你在使用硬编码,这时,如果用户变态的需求中确实遇到了一个switch case外的情况,那就不得不修改代码才有够实现他的需求。而现代程序的目标,就是使用软编码。(软编码(soft code)也许最早源于javascript,JS中的属性与方法均可能使用键名数组方式动态添加。)PHP为了实现这一点,专门增加了魔术函数__call(),__callstatic()。
     讲到这里,我们发现,从PHP5现行语言的特性来看,一个优秀的PHP程序员,是完全可以不用switch case这个控制结构的。
     但是,非常令人遗憾的是,Zend Framework中的case判断,多达3000多个。这是一个多么让人胆战心惊的数字?这说明,其中有多少,可以让人扩展的,没有放开扩展,可以让人配置的,没有让人配置,而被框架的写手直接写死了,如果有特殊需求,那你不得不改源码,这与其说是一个框架,不如说其只是一个可选用的代码库,仅此而己。

Jennycn 写道
3.
http://bardo.iteye.com/blog/666818
人说,Zend Framework的开发团队中,全是全世界最优秀的PHP程序员。我看这话说得是没有调查,也过于迷信。
     因为,Zend Framework中一样也有很多相当初级的代码。如果你不信,你可以自己找一些代码进行分析。
     我们举个简单的例子。有人说,优秀的PHP程序员,绝对不会使用switch case控制结构, 为什么?
     道理很简单,但这里不妨向大家说一下:
     1、PHP支持函数变量与对象变量,同时有强大的数组,因而能够直接形成变量与目标的映射。
     2、最新软件科学中,设计模式,代码重构,均是在不断讲解,避免使用switch case,比如,工厂模式,注册表模式,装载器模式,配置模式等。所有这些,最简单的实现方式就是不用这些模式,全能够用switch case实现。
     2、一旦使用switch case,那就证明了,你在使用硬编码,这时,如果用户变态的需求中确实遇到了一个switch case外的情况,那就不得不修改代码才有够实现他的需求。而现代程序的目标,就是使用软编码。(软编码(soft code)也许最早源于javascript,JS中的属性与方法均可能使用键名数组方式动态添加。)PHP为了实现这一点,专门增加了魔术函数__call(),__callstatic()。
     讲到这里,我们发现,从PHP5现行语言的特性来看,一个优秀的PHP程序员,是完全可以不用switch case这个控制结构的。
     但是,非常令人遗憾的是,Zend Framework中的case判断,多达3000多个。这是一个多么让人胆战心惊的数字?这说明,其中有多少,可以让人扩展的,没有放开扩展,可以让人配置的,没有让人配置,而被框架的写手直接写死了,如果有特殊需求,那你不得不改源码,这与其说是一个框架,不如说其只是一个可选用的代码库,仅此而己。

13 楼 Jennycn 2011-10-12  
http://www.jz123.cn/text/1230236.html

唉,要是p看到这篇文章,可能会更高兴一些

POJ是我们实验室的项目,现在的POJ基本上还沿用了2003年时的Serverlet代码结构,没有任何框架,视图和控制器都混在一起。这个学期打算要重构POJ,于是我就开始纠结到底用什么MVC框架。

  摆在我面前的选择有这么几个:

  asp.net

  php, Zend Framework框架

  Java, Struts2框架

  Python, Pylons或者Django框架

  我是Linux爱好者,所以首先排除asp.net。Python其实是一门很优秀的语言,面向对象做得很彻底,可以和各种其他语言粘合,两个热门框架也很不错。但是一方面我对python非常不熟悉,另一方面python的框架更新速度非常缓慢,近一年只更新了0.0.1,我对它的发展前景表示担忧,再加上中文资料太少,所以遗憾的排除。真正让我纠结的是Zend Framework和Struts2这两个框架。这两个框架我都使用过,感觉各有利弊。POJ本来的代码基于Java,因此重构的时候可以省一些事情。而图虫整个项目都是用Zend Framework,我对php和Zend Framework了如指掌,可以省却许多学习过程。但这都不足以说服我做出选择,还是比较一下框架之间的特性吧。

  php是动态脚本语言,在许多时候更加灵活。

  php是弱类型的,在变量处理的时候省却许多类型转换的麻烦。

  php不需要声明变量,大大减少代码量

  Zend Framework更加灵活,可以按需取用(use as wish),对于效率低下的部分,可以自己写代码替换。而Struts的框架核心代码则相对封闭

  Zend Framework自己就提供了功能库,方便调用各种Web Service。

  apache + php的结构更加便于热部署,只需要在服务器上svn update就可以了;而Java必须编译一下。这同时也有利于调试过程。

  php在任何地方都可以得到所需要的变量,在任何地方都可以执行任何函数或方法

  php有大量的开源项目,可以参考他们的代码,比如wordpress, joomla, phpBB, drupal, discuz, mediawiki;而Java的开源web项目,我一个都不知道

  php有许多超大规模网站的成功案例,比如:facebook,yahoo,wikipedia,baidu等;而Java,除了一个从网,我就不知道别的了

  struts2需要外加数据模型库,比如hibernate,非常不喜欢hibernate生成代码的方式,我认为hql完全没有必要;而zend Framework自己就提供了数据接口

  struts2的标签库完全是鸡肋

  struts2的布局系统需要外加别的模板库,比如sitemesh。而Zend Framework自己就能搞定

  php更加轻量,执行速度更快。而且很鲁棒。不会像JVM,因为一个Servelet挂掉而当机

  Java 的代码过于复杂,大量无聊的getter和setter简直是一场噩梦。做一件简单的事情也必须牵涉到几个对象和函数

  Zend Framework很年轻,开发远比Struts活跃。Zend Framework在一年内,从1.5升级到了1.9,期间包括近30个小版本,而Struts2在一年内仅仅从2.1.6升级到了2.1.8

  php今年来发展势头非常好,远比Java更活跃;Java在Sun被收购之后,各种改进明显受到影响

  总结起来,我们就能发现。php是为web而生的,各种特性都是为web而设计,web需要小巧,轻量,敏捷开发,php都能满足。而Zend Framework的诞生则让php的生命力在企业级应用上得以延续。而Java本来并不是为web而设计的,它过于笨重,在J2EE开发上有明显优势,但是对于web项目,未免有些杀鸡用牛刀。所以,最终我还是选择了Zend Framework

文章来自中国建站:http://www.jz123.cn/text/1230236.html
12 楼 Jennycn 2011-10-12  
http://blog.netroby.com/article-1706.html
Zend Framework缺陷一文中,指出了Zend Framework的三个问题,一个是Exception的处理,另一个是出错处理,最后一个是Zend Framework代码质量问题。

作者认为Zend Framework的设计过于松散,所以会出现结合不紧密。原文说Zend Framework太松散,所以在处理Exception和出错上不是很灵活。在这里,我想说的是,Zend Framework只是一个官方通用版的框架,它是一种很理想化的思路,它的设计指导思想oop是没错的。oop的真义就是对象不对事,拆解业务逻辑,这是真正的设计之道。如果你自己开发一个框架,未必能把oop做的比Zend Framework.  也许你会反击我,你说你己经有框架开发经验,那么你再想想,你的框架在面临任何开发应用需求的情况下,是否都能从容应对呢?我看过国内外多数框架的衍进史,它们的功能都是慢慢补充,慢慢增加的,开始可能很小巧,但后来因为业务需求,慢慢变的越来越庞大,不合理的地方也渐渐有了不同的争论,直到它要么斧正过来,要么被抛弃。


你有自己的理解,可以在Zend Framework的基础上,进行自己的自定义,这是完全可行的。你还可以不屑于用Zend Framework,自己吃自己的狗粮。但是,你能保证你能搞定所有问题么?站在巨人的肩膀上,我们才能看的更远。Zend Framework的维护者,来自世界一线的开发团队。他们来自不同的公司,但他们都是非常经验丰富的开发人员,他们可以代表一种敏锐的开发趋势。最重要的是,他们背后的企业,正是开发php的Zend, php的变化,在Zend Framework里面得以淋漓尽致的展现,你可以用不Zend Framework,但你的确需要好好研究一下它。一定会让你受益菲浅。
Zend Framework自身也在快速发展之中,每一个版本的更新,都要修正很多问题,而且Zend Framework的产品周期非常活跃,非常稳定。一个月就有一个小幅或大幅更新。很难想象一个长期缺乏维护的框架怎么能堪以重用?

如果你是企业应用开发,一定需要一个有持续生命力的工具框架来支撑,这个时候,Zend Framework就是你的不二之选。其它团队和个人开发的框架也许会放弃开发或者因财务不济而退出这个领域,但我相信Zend 可以走的更久一点。

Zend Framework  缺陷一文中提到的仅仅是表面上的这些问题,Zend Framework 2.0版本己经在着手开发了 ,也许会有新的设计方式出现,不管怎么样,我乐见其成。对于Zend Framework,我会保持关注,对于Zend 公司,我还是非常有信心,他们能把Framework做好。每一个版本的改进,都会扔掉一些陈旧的,质量不好的代码,这一点是有目共睹的,因此不要过于担心Zend Framework的代码Bug以及设计模式的不合理。它一直在成长,一直在改变。

php的灵魂人物之一的Andi也在Framework的开发人员名单上。我相信,Zend Framework一定可以算的上是开发领域的主流力量。不容诋毁的,也无法抹去它的贡献。如果对Zend Framework真的有不满,倒真的可以申请成为代码维护者,与其自己另起门户,费心费力,为何不努力做一点贡献给开源社区?

Zend Framework, 大家完全可以放心的用,不用担心有什么大的故障和问题,它是一个工具,工具是被用的,人不应该受制于工具。

小型应用开发,不一定要用Zend Framework. Zend Framework只是给你多一种选择而己。

11 楼 Jennycn 2011-10-12  
http://bbs.phpchina.com/thread-29411-2-1.html

mikespook

这个人好像也比较熟悉zend
10 楼 Jennycn 2011-10-12  
看到好几人提到那个symfony

http://www.zfeye.com/archives/58.html

几款主流PHP框架的优缺点评比
icefox @ 2010 年 12 月 25 日 下午 6:32 | 没有评论 | 评论 Feed | Trackback

标签:CakePHP, CodeIngiter, php, Symfony, Zend Framework, 框架

PHP语言还是比较常用到的一门计算机高级语言。我们将会在这篇文章中向大家主要介绍关于PHP框架相关优缺点评比,作为一个参考风险给朋友们。

主要参考的PHP框架包括:CodeIgniter、CakePHP、ZendFramework、Symfony。我对很多框架也没有认真使用,只是简单试用了一下,可能很多看法不成熟或者是错误的,请大家指正,一起成长。

CodeIgniter

优点:

1. 配置简单,全部的配置使用PHP脚本来配置,执行效率高;具有基本的路由功能,能够进行一定程度的路由;具有初步的Layout功能,能够制作一定程度的界面外观;数据库层封装的不错,具有基本的MVC功能

2. 快速简洁,代码不多,执行性能高,PHP框架简单,容易上手,学习成本低,文档详细;自带了很多简单好用的library,框架适合小型应用

缺点:

1. 把Model层简单的理解为数据库操作

2. PHP框架略显简单,只能够满足小型应用,略微不太能够满足中型应用需要

评价:

总体来说,拿CodeIgniter来完成简单快速的应用还是值得,同时能够构造一定程度的layout,便于模板的复用,数据操作层来说封装的不错,并且CodeIgniter没有使用很多太复杂的设计模式,执行性能和代码可读性上都不错。至于附加的 library 也还不错,简洁高效。

CakePHP

优点:

1. CakePHP是最类似于RoR的PHP框架,包括设计方式,数据库操作的Active Record方式;设计层面很优雅,没有自带多余的 library,所有的功能都是纯粹的框架,执行效率还不错;数据库层的 hasOne, hasMany 功能很强大,对于复杂业务处理比较合适;路由功能,配置功能还不错;自动构建脚手架(scaffold)很强大;适合中型应用;基本实现过了MVC每一层;具有自动操作命令行脚本功能;

2. 文档比较全,在国内推广的比较成功,大部分都知道CakePHP,学习成本中等

缺点:

1. CakePHP非常严重的问题是把Model理解为数据库层操作,严重影响了除了数据库之外的操作能力

2. CakePHP的cache功能略显薄弱,配置功能稍嫌弱;CakePHP不适合大型应用,只适合中型应用,小型应用来说略微的学习成本高了点

评价:

总体来说CakePHP框架代表了PHP框架很重要的一个时代和代表,并且目前发挥着很重要的作用,不少自己写的框架都模仿了CakePHP的方式,是个里程碑式的产品;CakePHP透露着RoR的敏捷开发方式和把数据库操作认为是唯一Model的设计思想,作为开发快速应用和原型是绝好的工具;同样,用来做Web2.0网站的开发框架,也是值得选择的。

Zend Framework

优点:

1. 官方出品,自带了非常多的 library,框架本身使用了很多设计模式来编写,架构上很优雅,执行效率中等;MVC设计中,比较简洁,具有路由功能,配置文件比较强大(能够处理XML和php INI),各种 library 很强大,是所有PHP框架中各种功能最全面的,包括它不仅是一个PHP框架,更是一个大类库(取代PEAR),这是它的主要特色;能够直观的支持除数据库操作之外的Model层(比 CodeIgniter 和 CakePHP 强),并且能够很轻易的使用Loader功能加载其他新增加的Class;Cache功能很强大,从前端Cache到后端Cache都支持,后端Cache支持Memcache、APC、SQLite、文件等等方式;数据库操作功能很强大,支持各种驱动(适配器)

2. 文档很全,在国内社区很成熟,并且目前不少Web 2.0网站在使用,学习成本中等

缺点:

1. MVC功能完成比较弱,View层简单实现(跟没实现一样),无法很强大的控制前端页面

2. 没有自动化脚本,创建一个应用,包括入口文件,全部必须自己手工构建,入门成本高

3. Zend Framework 作为一个中型应用框架问题不大,也能够勉强作为大型应用的PHP框架,但是作为一个很成熟的大型PHP框架来说,还需要一些努力

评价:

作为官方出品的框架,Zend Framework的野心是可以预见的,想把其他框架挤走,同时封装很多强大的类库,能够提供一站式的框架服务,并且他们的开发团队很强大,完全足够有能力开发很强大的产品出来,所以基本可以确定的是Zend Framework前途无量,如果花费更多的时间去完善框架。同样的,Zend Framework架构本身也是比较优雅的,说明Zend官方是有很多高手的,设计理念上比较先进,虽然有一些功能实现的不够完善,比如View层,自动化脚本等等,这些都有赖于未来的升级。总体来说Zend Framework是最值得期待的PHP框架,当然,你目前要投入你的项目中使用也是完全没问题的。

Symfony

优点

1. Symfony 是我了解的PHP框架中功能最强大的,而且我使用时间比较长,但是很多功能还是没有挖掘出来;它完整实现了MVC三层,封装了所有东西,包括 $_POST,$_GET 数据,异常处理,调试功能,数据检测;包含强大的缓存功能,自动加载Class(这个功能很爽),强大的i18n国家化支持;具有很强大的view层操作,能够零碎的包含单个多个文件;非常强大的配置功能,使用yml配置能够控制所有框架和程序运行行为,强大到让人无语;能够很随意的定义各种自己的class,并且symfony能够自动加载(auto load)这些class,能够在程序中随意调用;包含强大的多层级项目和应用管理:Project –> Application –> Module –> Action,能够满足一个项目下多个应用的需要,并且每层可以定义自己的类库,配置文件,layout;非常强大的命令行操作功能,包括建立项目、建立应用、建立模块、刷新缓存等等;

2. Symfony绝对是开发大型复杂项目的首选,因为使用了Symfony,将大大节约开发成本,并且多人协作的时候,不会出现问题,在Project级别定义好基础Class以后,任何模块都能够重用,大大复用代码

缺点:

1. 数据库操作model采用了重量级的propel和creole,不过在我测试的版本中已经把他们移到了addon里,可用可不用

2. 缓存功能无法控制,每次开发调试总是缓存,需要执行 symfony cc, symfony rc 来清除和重建缓存;

3. 效率不是很高,特别是解析模板和读取配置文件的过程,花费时间不少;

4. 学习成本很高,并且国内没有成熟的社区和文档,连中文手册都没有,相应的要掌握所有功能,需要花费比较多的时间

评价:

Symfony绝对是企业级的PHP框架,唯一能够貌似能够跟Java领域哪些强悍框架抗衡的东西;强悍的东西,自然学习复杂,但是相应的对项目开发也比较有帮助,自然是推荐复杂的项目使用Symfony来处理,觉得是值得,后期的维护成本比较低,复用性很强。相应的如果使用Symfony的应该都是比较复杂的互联网项目,那么相应的就要考虑关于数据库分布的问题,那么就需要抛弃Symfony自带的数据库操作层,需要自己定义,当然了,Symfony支持随意的构造model层。

总结

以上数款PHP框架,各有特色,而且都是开源项目,不过框架针对的项目不一样,一般来说 CodeIngiter 比较适合小型项目,CakePHP 和 Zend Framework 比较适合中型项目,Symfony 比较适合大型重量级项目,在项目选型的时候,要充分考虑框架的可以定制性、扩展性,因为每个项目都无法确定你是否会随着需求的变化进行改变。

相对来说,Zend Framework 和 Symfony 应对变化的能力比较强,特别是能够随意定制 model 层的Class,能够非常方便增加自己业务或者数据处理类,我是个人比较推荐在中大型项目中使用的PHP框架。

CodeIngiter 和 CakePHP 在中小型项目中同样能够发挥重大作用,快速开发和原型构建,非常适合
9 楼 Jennycn 2011-10-12  
http://blog.csdn.net/a82168506/article/details/6323579

这个人是一个zend 高手,看来
8 楼 Jennycn 2011-10-12  
php的优缺点http://blog.csdn.net/a82168506/article/details/6664714



php优点

1. 跨平台,性能优越,跟Linux/Unix结合别跟Windows结合性能强45%,并且和很多免费的平台结合非常省钱,比如LAMP(Linux /Apache/Mysql/PHP)或者FAMP(FreeBSD/Apache/Mysql/PHP)结合,或者数据应用够大可以考虑换 PostgreSQL或者Oracle,支持N种数据库。(N >= 10)

2. 语法简单,如果有学习C和Perl的很容易上手,并且跟ASP有部分类似。有成熟的开发工具,比如NuPHPed,或者Zend Studio等等,再Linux平台下可以使用Eclipse等等。

3. 目前主流技术都支持,比如WebService、Ajax、XML等等,足够应用。

4. 有比较完整的支持,比如使用ADODB或者PEAR::DB做数据库抽象层,用Smarty或者smart template做模板层,如果是PHP 5.1的话,还能够使用PDO(PHP Data Object)来访问数据库。

5. 有很多成熟的框架,比如支持MVC的框架:phpMVC,支持类似ASP.net的事件驱动的框架:Prado,支持类似Ruby On Rails的快速开发的框架:Cake等等,足够满足你的应用需求。

6. PHP 5已经有成熟的面向对象体系,能够适应基本的面向对象要求。适合开发大型项目。

7. 有成熟的社区来支持PHP的开发。


8. 目前已经很多大型应用都是使用PHP,比如淘宝网、Yahoo、163、Sina等等大型门户,很多选用PHP来作为他们的开发语言,所以大型门户都能够选用它,我想足够能够你的使用了。




9. 有很多开源的框架或开源的系统可以使用,比如比较知名的开源框架有Zend Framework、CakePHP、CodeIgniter、symfony等,开源论坛有Discuz!、Phpwind等,开源博客 WordPress,开源网店系统如Ecshop、ShopEx等,开源的SNS系统如UCHome、ThinkSNS等。


缺点

1.对多线程支持不太好,大多数时候我们只能简单的模拟去实现的。




2.语法不太严谨,比如变量不需要定义就可以使用,在c,java,c++中变量是必须先定义以后才可以使用的。




3.也许有经验的PHP程序员最感到痛苦的地方是PHP的解释运行机制。这种运行机制使得每个PHP页面被解释执行后,所有的相关资源都会被回收。也就是说,PHP在语言级别上没有办法让某个对象常驻内存。在PHP中,所有的变量都是页面级的,无论是全局变量,还是类的静态成员,都会在页面执行完毕后被清空。以JSP为例,在JSP中,Java Bean的scope有四种有效值:Page、Application、Session、Request,分别对应页面、程序、会话、请求四种生存期。但在PHP中,只有Page一种生存期。

7 楼 Jennycn 2011-10-12  
http://blog.csdn.net/a82168506/article/details/6664704

优点:

Zend Framework大量应用了PHP5中面向对象的新特征:接口、异常、抽象类等等。这些东西的应用让Zend Framework具有高度的模块化和灵活性。同时,严格遵循“针对接口编程”和“单一对象职责”等原则.

1. 官方出品,自带了非常多的 library,框架本身使用了很多设计模式来编写,架构上很优雅,执行效率中等;MVC设计中,比较简洁,具有路由功能,配置文件比较强大(能够处理 XML和php INI),各种 library 很强大,是所有PHP框架中各种功能最全面的,包括它不仅是一个PHP框架,更是一个大类库(取代PEAR),这是它的主要特色;能够直观的支持除数据库操作之外的Model层(比 CodeIgniter 和 CakePHP 强),并且能够很轻易的使用Loader功能加载其他新增加的Class;Cache功能很强大,从前端Cache到后端Cache都支持,后端 Cache支持Memcache、APC、SQLite、文件等等方式;数据库操作功能很强大,支持各种驱动(适配器)

2. 文档很全,在国内社区很成熟,并且目前不少Web 2.0网站在使用,学习成本中等







缺点:


1. 因为功能比较庞大等原因,入门成本较高


2. 整个框架比较庞大臃肿,运行速度相对较慢,不太适合小型项目




3. 版本升级较快,而一个项目如果长期维护,且升级到当前最高版本时产生的兼容性问题比较头疼



评价:

作为官方出品的框架,Zend Framework的野心是可以预见的,想把其他框架挤走,同时封装很多强大的类库,能够提供一站式的框架服务,并且他们的开发团队很强大,完全足够有能力开发很强大的产品出来,所以基本可以确定的是Zend Framework前途无量,如果花费更多的时间去完善框架。同样的,Zend Framework架构本身也是比较优雅的,说明Zend官方是有很多高手的,设计理念上比较先进,这些都有赖于未来的升级。总体来说Zend Framework是最值得期待的PHP框架,当然,你目前要投入你的项目中使用也是完全没问题的。

6 楼 Jennycn 2011-10-12  
5
上一节我们说到,Zend Framework中的一些代码是相当初级的,但我们只是举了控制结构的使用。现在我们来给出真正的代码实例。也许,你马上会说,这不仅是初级代码,简直就是垃圾代码。我敢打赌,你会有这样的感受。
     这里我们要说的是Zend_Date。如果你没能看过这个类的代码,那好,现在我建议,你最好先打开看一下。我们的打开library\Zend\Date.php.
    下面我来跟您讲一下,这个代杩为什么垃圾。首先,作者试图要把我们对 Datetime操作的需求完全收录到这个类中,提供完全的代码给大家使用。这也许是好事。但如果你看一下代码,就会发现,作者试图包办一切。并且,某种程度上,我不得不说,作者的真实意图,是在摆显,他有多大能耐。然而,可悲的是:越是摆显,越是让我们发现,作者是如何初级。
     整个类有近5000行的代码,可见作者的“良苦用心”!!!此类中一个方法:function _calculate,这个方法的长度居然近1400多行。作者怪异地把 'add'|'sub'|'cmp'|'copy'|'set' 这五种运算合并到一个方法中。完全违背了一个函数做一个事的基本原则。而且,用户面临的是什么?无法对此函数产生信任。因为,这行长的代码,根本不是一两下子能够看懂看完的。记得一次微软公司的开发讲座上,说到微软公司要求每一个函数最长不能超过140行。试想,如果这个函数出错,(BUG总是难免的)那么,你必须得花时间弄懂这1400行代码。(上一节我们说了switch case控制结构,这个类中,可能是全框架用switch case控制结构最多的。)
    反过来,如果我们把这些运算分开来,日期时间的操作,只要用户了解相关函数,分多行代码操作,那代码量会少得多,而不会背上这么多的又臭又长的垃圾代码!!Zend Framework有40M代码,不难想象,40M的代码,其中含了多少垃圾,由这一类原因造成的代码长度超标肯定不只这里一处!
    比如,我们写个DateAdd函数,不超过10行代码就可完成:
Php代码 
function dateAdd($interval, $number, $date=null, $format="Y-m-d"){   
    $date=($date?$date:date("Y-m-d"));  
    $interval_param=array("s"=>1,"n"=>60,"h"=>3600,"d"=>86400,"ww"=>604800,"m"   =>'',"yyyy"=>31556952);     
    if ($interval != "m")  
        return date($format,strtotime($date)+$interval_param[$interval]*$number);   
    else{  
        $dt_arr=getdate(strtotime($date));  
        return date($format,mktime($dt_arr[hours],$dt_arr[minutes],$dt_arr[seconds],$dt_arr[mon]+$number,$dt_arr[mday],$dt_arr[year]));  
    }  


function dateAdd($interval, $number, $date=null, $format="Y-m-d"){
$date=($date?$date:date("Y-m-d"));
$interval_param=array("s"=>1,"n"=>60,"h"=>3600,"d"=>86400,"ww"=>604800,"m" =>'',"yyyy"=>31556952);
if ($interval != "m")
return date($format,strtotime($date)+$interval_param[$interval]*$number);
else{
$dt_arr=getdate(strtotime($date));
return date($format,mktime($dt_arr[hours],$dt_arr[minutes],$dt_arr[seconds],$dt_arr[mon]+$number,$dt_arr[mday],$dt_arr[year]));
}
}


    而且,我们可以看出,代码易懂,用户易于信任。从这一点看出,Zend Framework作为官方的PHP框架,这种缺陷是致命的。尽管我们清楚, Zend Framework的目标是挤掉所有非官方的框架。但从现实情况看,他们是在做梦!!
5 楼 Jennycn 2011-10-12  
4

上一节我们说到,Zend Framework中的一些代码是相当初级的,但我们只是举了控制结构的使用。现在我们来给出真正的代码实例。也许,你马上会说,这不仅是初级代码,简直就是垃圾代码。我敢打赌,你会有这样的感受。
     这里我们要说的是Zend_Date。如果你没能看过这个类的代码,那好,现在我建议,你最好先打开看一下。我们的打开library\Zend\Date.php.
    下面我来跟您讲一下,这个代杩为什么垃圾。首先,作者试图要把我们对 Datetime操作的需求完全收录到这个类中,提供完全的代码给大家使用。这也许是好事。但如果你看一下代码,就会发现,作者试图包办一切。并且,某种程度上,我不得不说,作者的真实意图,是在摆显,他有多大能耐。然而,可悲的是:越是摆显,越是让我们发现,作者是如何初级。
     整个类有近5000行的代码,可见作者的“良苦用心”!!!此类中一个方法:function _calculate,这个方法的长度居然近1400多行。作者怪异地把 'add'|'sub'|'cmp'|'copy'|'set' 这五种运算合并到一个方法中。完全违背了一个函数做一个事的基本原则。而且,用户面临的是什么?无法对此函数产生信任。因为,这行长的代码,根本不是一两下子能够看懂看完的。记得一次微软公司的开发讲座上,说到微软公司要求每一个函数最长不能超过140行。试想,如果这个函数出错,(BUG总是难免的)那么,你必须得花时间弄懂这1400行代码。(上一节我们说了switch case控制结构,这个类中,可能是全框架用switch case控制结构最多的。)
    反过来,如果我们把这些运算分开来,日期时间的操作,只要用户了解相关函数,分多行代码操作,那代码量会少得多,而不会背上这么多的又臭又长的垃圾代码!!Zend Framework有40M代码,不难想象,40M的代码,其中含了多少垃圾,由这一类原因造成的代码长度超标肯定不只这里一处!
    比如,我们写个DateAdd函数,不超过10行代码就可完成:
Php代码 
function dateAdd($interval, $number, $date=null, $format="Y-m-d"){   
    $date=($date?$date:date("Y-m-d"));  
    $interval_param=array("s"=>1,"n"=>60,"h"=>3600,"d"=>86400,"ww"=>604800,"m"   =>'',"yyyy"=>31556952);     
    if ($interval != "m")  
        return date($format,strtotime($date)+$interval_param[$interval]*$number);   
    else{  
        $dt_arr=getdate(strtotime($date));  
        return date($format,mktime($dt_arr[hours],$dt_arr[minutes],$dt_arr[seconds],$dt_arr[mon]+$number,$dt_arr[mday],$dt_arr[year]));  
    }  


function dateAdd($interval, $number, $date=null, $format="Y-m-d"){
$date=($date?$date:date("Y-m-d"));
$interval_param=array("s"=>1,"n"=>60,"h"=>3600,"d"=>86400,"ww"=>604800,"m" =>'',"yyyy"=>31556952);
if ($interval != "m")
return date($format,strtotime($date)+$interval_param[$interval]*$number);
else{
$dt_arr=getdate(strtotime($date));
return date($format,mktime($dt_arr[hours],$dt_arr[minutes],$dt_arr[seconds],$dt_arr[mon]+$number,$dt_arr[mday],$dt_arr[year]));
}
}


    而且,我们可以看出,代码易懂,用户易于信任。从这一点看出,Zend Framework作为官方的PHP框架,这种缺陷是致命的。尽管我们清楚, Zend Framework的目标是挤掉所有非官方的框架。但从现实情况看,他们是在做梦!!
4 楼 Jennycn 2011-10-12  
3.
http://bardo.iteye.com/blog/666818
人说,Zend Framework的开发团队中,全是全世界最优秀的PHP程序员。我看这话说得是没有调查,也过于迷信。
     因为,Zend Framework中一样也有很多相当初级的代码。如果你不信,你可以自己找一些代码进行分析。
     我们举个简单的例子。有人说,优秀的PHP程序员,绝对不会使用switch case控制结构, 为什么?
     道理很简单,但这里不妨向大家说一下:
     1、PHP支持函数变量与对象变量,同时有强大的数组,因而能够直接形成变量与目标的映射。
     2、最新软件科学中,设计模式,代码重构,均是在不断讲解,避免使用switch case,比如,工厂模式,注册表模式,装载器模式,配置模式等。所有这些,最简单的实现方式就是不用这些模式,全能够用switch case实现。
     2、一旦使用switch case,那就证明了,你在使用硬编码,这时,如果用户变态的需求中确实遇到了一个switch case外的情况,那就不得不修改代码才有够实现他的需求。而现代程序的目标,就是使用软编码。(软编码(soft code)也许最早源于javascript,JS中的属性与方法均可能使用键名数组方式动态添加。)PHP为了实现这一点,专门增加了魔术函数__call(),__callstatic()。
     讲到这里,我们发现,从PHP5现行语言的特性来看,一个优秀的PHP程序员,是完全可以不用switch case这个控制结构的。
     但是,非常令人遗憾的是,Zend Framework中的case判断,多达3000多个。这是一个多么让人胆战心惊的数字?这说明,其中有多少,可以让人扩展的,没有放开扩展,可以让人配置的,没有让人配置,而被框架的写手直接写死了,如果有特殊需求,那你不得不改源码,这与其说是一个框架,不如说其只是一个可选用的代码库,仅此而己。
3 楼 Jennycn 2011-10-12  
P简直被他们的proposal迷住了,可是,唉,为啥我总是对框架有担心呢

刚刚搜索到一个连载的谈论zend framework的缺陷的


http://bardo.iteye.com/blog/672696

2
细说Zend的错误管理。
我们还是接着上一次的话题。上一次我们说了,Zend的最大缺陷是异常管理类。实际远非如此。Zend本着松耦合的原测,使得类与类之间基本没有什么关联。按理说,这是比较好的。但这却带来了一个相当大的问题。
那就是没一个类都把自己管好,每一个类都各自为政。最大的问题就是错误管理。初步统计了一下,Zend代码中使用set_error_handler的地方不下于60处。如此之多的地方,这也就使得程充无法对错误进行真正的集中管理,集中写错误日志。
也许,有人会说,这有必要吗?
举个简单的例子。某个网友,曾给我约近10个用Zend开发的网站,无论是用QUERYSTRING的URL还是伪静态的URL,只要你在URL中添中足够长的非法参数,网站均出错。
也许你会说,这是GET能数较验与过滤的问题。话是这么说,一方面我们可以想象,开发者较初级,但相对于高级的开发者,相对于开发团队,这个的疏饭也是难免的。而出错的位置是不同的。并不会都在较验与过滤部分。因而,这使得使用zend对错误集中管理成了一个大问题。
也话你会说,zend是面向企业级开发的。因而,使用zend,普通类,均应使用异常对错误进行管理。但如果是写一个核心类呢?使用zend不需要再加什么内核。实际并非如此。比如zend没有很好的RPN类,那么,我要写这样的类时,也不不得服从它的模式,set_error_handler,而不能用trigger_error将错误交给应用系统了。
由此看出。40M巨大的类库,不但学习培训成本高,对开发团队的开发人员的素质要求也高。有人说,大型团群众观点合作,zend能看出其优势,但我看不出有什么优势。
2 楼 Jennycn 2011-10-12  
他们还提到了PSD--html

我理解的是,把静态效果图,转化为网页

*.psd(Adobe PhotoShop Document)/*.pdd *.psd是PhotoShop中使用的一种标准图形文件格式,可以存储成RGB或CMYK模式,还能够自定义颜色数并加以存储。*.psd文件能够将不同的物件以层(L ayer)的方式来分离保存,便于修改和制作各种特殊效果。
1 楼 Jennycn 2011-10-12  
http://blog.csdn.net/bingqing07/article/details/6315017

想理解zend框架的工作原理,首先就需理解什么是MVC程序设计方法.

模型(model):定义了一个应用程序所要表示的过程的有关规则
视图(view):负责对模型返回的数据格式化,并提供给用户
控制器(controller):负责确定应用程序如何根据用户的操作,调用适当的模型和视图做出响应。

假设有一个这样的场景,用户需要登录某个网站,mvc是如何工作的:
1).用户输入登录名和密码,然后用户按enter键提交了这个表单。
2).控制器做出响应,识别适当的动作,收集输入的登录名和密码,并把数据提供给模型处理。
3).模型执行负责判断用户名输入的登录名和密码是否为本网站用户,并把结果值返回给控制器。
4).控制器调用适当视图,并传入相应的值。视图把成功登录的结果显示给用户。

zend框架就是就是这样工作的

相关推荐

Global site tag (gtag.js) - Google Analytics