又是一盘面条啊
看了一眼index.php的代码,真是一种不能忍受的coding风格
回复#3 @小明 :
我知道你想说用ORM,几年前我就用ORM。 但是ORM的抽象能力是有限的,在需要分页优化的复杂SQL情况下,你的ORM实现后也不见得能看。
并且简单的SQL本身也非常易读,不易出错,ORM化后反而失去了这个优点。
原来版本:
$TopicsArray = $DB->query(' SELECT `ID`, `Topic`, `Tags`, `UserID`, `UserName`, `LastName`, `LastTime`, `Replies` FROM ' . $Prefix . 'topics force index(LastTime) WHERE IsDel=0 ORDER BY LastTime DESC LIMIT ' . ($Page - 1) * $Config['TopicsPerPage'] . ',' . $Config['TopicsPerPage']);
这是你十分推崇的ORM写法:
$topics = new Topics(); $topics->show( array( 'ID', 'Topic', 'Tags', 'UserID', 'UserName', 'LastName', 'LastTime', 'Replies' ) ); $topics->find( array( 'IsDel' => 0 ) ); $topics->sortBy(function($topics){ return $topics->LastTime ; }); $topics->limit( ($Page - 1) * $Config['TopicsPerPage'], $Config['TopicsPerPage']) ); $TopicsArray = $topics->getAll();
这还只是最简单的SQL,如果是我第二条为了分页性能优化的SQL,ORM化后会如何呢?
可想而知,第二条SQL ORM后写个50行不是问题。这种ORM就属于垃圾代码了,又臭又长,你通读一遍可能都忘了前面是什么了。不通读更是什么都不懂。
我知道有很多人学框架里的傻瓜工具,学到SQL都不会了,这种情况下其实就是ORM化了他们也看不懂。
回复#8 @小明 :
如果你说的是MVC,那也是经典架构,在Java中非常流行。
可是PHP的设计有所不同,文件本身就可以充当Controller,这是解释器中实现的,Rewrite更是可以非常好地实现Controller,也算一种另类的MVC实现。
根据PHP 之父 Rasmus Lerdorf 的看法:
Q:这种规画网站的方式,什麽是最重要的关键?
A:关键是你必须建立分离、模组化的独立端点,而不是全部放在同一个大篮子裡。大多数现今MVC架构(MVC framework)的开发框架(Framework),使用所谓的前端控制器(Front Control),每一次浏览器提出Request请求时,就会呼叫这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程式。这样做,一点意义都没有。
在浏览器层次,程式完全能知道使用者想要做什麽事情,例如使用者只是要读信,程式就不用再把需求送到伺服器,让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器,由伺服器处理,就会浪费大量伺服器资源,来处理那些对使用者没有实际功用的工作。扩充性来自架构,很多开发框架,将所有事情绑在一起,限制了架构。选错开发框架,你就没有扩充性。
Q:你是说MVC模式不利于网站扩充性?
A:MVC模式比较适合用在网页控制器(Page Control)的层次。基本上,每一个网页控制器都是独立模组,读信和查地址是不同的网页控制器,所以,读信程式就不会干扰到查地址程式。所以,在每一个端点使用MVC模式来打造小型的网页控制器,是不会有问题。但是,大多数採用MVC模式的框架,预设在网站中採用前端控制器,而非用网页控制器的方式,这样的MVC模式,只适合在小型或单一伺服器的网站。
Q:你会如何选择开发框架呢?
A:一个框架都不要用。但是,我会从这些开发框架中,找出我需要的功能,拿出那个我需要的程式模组来用,或者参考其中的设计想法,而不是套用整个框架。我所看到的大多数框架,都没有专注在打造有效能的扩充性和可模组性。
Q:难道开发者不需要框架或架构吗?
A:网站的确需要有架构,每一个人都需要框架,框架是一种解决问题的方法。但是你并不需要通用型框架,用一个前端控制器,来解决所有问题,这样通常没办法成功。每一个问题都不同,你需要引导框架,使用正确的设计模式,直接解决真正要处理的问题。只生产一款汽车,怎麽可能满足全世界人的需求!
用框架开发雏形系统就好,但真正的产品就不要全部套用。从框架开始比较容易,但你要拆开全部的框架,移除Runtime检查、拿掉不需要的功能,只留下你会用到的程式模组。你不需要一个通用型框架,因为它无法提供未来的扩充性,但也不用重头写起,你需要的是介于两者之间。
1、我说代码有问题,是缺少封装和重用,各种过程式的代码书写对后续的维护并无多大好处,举一个简单的栗子,就那个取TopicsArray,其他地方如果调用的话,难道你再copy一遍你的代码吗?
2、我有点无语了
如果你说的是MVC,那也是经典架构,在Java中非常流行。
对于这个我只想说,php中也非常流行,让代码结构清晰好维护
3、至于orm
我知道你想说用ORM,几年前我就用ORM。
这个真的是你自己的臆想
并且我想说,orm的实现看水平了,我不想多说。
4、请不要断章取义,请看作者想要表达的是什么吧
Q:这种规画网站的方式,什麽是最重要的关键?
A:关键是你必须建立分离、模组化的独立端点,而不是全部放 在同一个大篮子裡。大多数现今MVC架构(MVC framework)的开发框架(Framework),使用所谓的前端控制器(Front Control),每一次浏览器提出Request请求时,就会呼叫这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程式。这样做,一点意义 都没有。
在浏览器层次,程式完全能知道使用者想要做什麽事情,例如使用者只是要读信,程式就不用再把需求送到伺服 器,让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器,由伺服器处理,就会浪费大量伺服器资源,来处理那些对使用者没有实际功用的工作。扩充 性来自架构,很多开发框架,将所有事情绑在一起,限制了架构。选错开发框架,你就没有扩充性。
Q:你是说MVC模式不利于网站扩充性?
A:MVC 模式比较适合用在网页控制器(Page Control)的层次。基本上,每一个网页控制器都是独立模组,读信和查地址是不同的网页控制器,所以,读信程式就不会干扰到查地址程式。所以,在每一 个端点使用MVC模式来打造小型的网页控制器,是不会有问题。但是,大多数採用MVC模式的框架,预设在网站中採用前端控制器,而非用网页控制器的方式, 这样的MVC模式,只适合在小型或单一伺服器的网站。
Q:你会如何选择开发框架呢?
A:一个框架都不要用。但是,我会从这些开发框架中,找出我需要的功能,拿出那个我需要的程式模组来用,或者参考其中的设计想法,而不是套用整个框架。我所看到的大多数框架,都没有专注在打造有效能的扩充性和可模组性。
Q:难道开发者不需要框架或架构吗?
A:网站的确需要有架构,每一个人都需要框架,框架是一种解决问题的方法。但是你并不需要通用型框架,用一个前端控制器,来解决所有问题,这样通常没办法成 功。每一个问题都不同,你需要引导框架,使用正确的设计模式,直接解决真正要处理的问题。只生产一款汽车,怎麽可能满足全世界人的需求!
用框架开发雏形系统就好,但真正的产品就不要全部套用。从框架开始比较容易,但你要拆开全部的框架,移除Runtime检查、拿掉不需要的功能,只留下你会用到的程式模组。你不需要一个通用型框架,因为它无法提供未来的扩充性,但也不用重头写起,你需要的是介于两者之间。
登录后方可回帖
风格我觉得看个人喜好吧。
https://github.com/lincanbin/Carbon-Forum/blob/master/index.php
index.php这几十行代码我觉得并没有什么问题,这里面甚至主要还是SQL,易读也易懂,没感觉出有什么不好的地方了。