`
bardo
  • 浏览: 372812 次
  • 性别: Icon_minigender_1
  • 来自: 上海
博客专栏
D1407912-ab64-3e76-ae37-b31aa4afa398
浅述PHP设计模式
浏览量:11641
9d6df9f7-91da-3787-a37c-0e826525dd5d
Zend Framewor...
浏览量:9994
85b628bd-a2ed-3de2-a4b1-0d34985ae8b6
PHP的IDE(集成开发环...
浏览量:9353
社区版块
存档分类
最新评论

Zend Framework的缺陷(连载之2)

    博客分类:
  • PHP
阅读更多
细说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能看出其优势,但我看不出有什么优势。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics