又是一盘面条啊
By 小明
at 2015-10-08
0人收藏 • 5288人看过
看了一眼index.php的代码，真是一种不能忍受的coding风格
- 登录后方可回帖
风格我觉得看个人喜好吧。
<?php
require(__DIR__ . '/common.php');
require(__DIR__ . '/language/' . ForumLanguage . '/home.php');
$Page = intval(Request('Get', 'page'));
$TotalPage = ceil($Config['NumTopics'] / $Config['TopicsPerPage']);
if ($Page < 0 || $Page == 1) {
header('location: ' . $Config['WebsitePath'] . '/');
exit;
}
if ($Page > $TotalPage) {
header('location: ' . $Config['WebsitePath'] . '/page/' . $TotalPage);
exit;
}
if ($Page == 0)
$Page = 1;
$TopicsArray = array();
if ($MCache && $Page == 1) {
$TopicsArray = $MCache->get(MemCachePrefix . 'Homepage');
}
if (!$TopicsArray) {
if ($Page <= 10) {
$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']);
if ($MCache && $Page == 1) {
$MCache->set(MemCachePrefix . 'Homepage', $TopicsArray, 600);
}
} else {
$TopicsArray = $DB->query('SELECT `ID`, `Topic`, `Tags`, `UserID`, `UserName`, `LastName`, `LastTime`, `Replies`
FROM ' . $Prefix . 'topics force index(LastTime)
WHERE LastTime<=(SELECT LastTime
FROM ' . $Prefix . 'topics force index(LastTime)
WHERE IsDel=0
ORDER BY LastTime DESC
LIMIT ' . ($Page - 1) * $Config['TopicsPerPage'] . ',1)
and IsDel=0
ORDER BY LastTime DESC
LIMIT ' . $Config['TopicsPerPage']);
}
}
$DB->CloseConnection();
$PageTitle = $Page > 1 ? ' Page' . $Page . '-' : '';
$PageTitle .= $Config['SiteName'];
$PageMetaDesc = htmlspecialchars(mb_substr($Config['SiteDesc'], 0, 150, 'utf-8'));
$ContentFile = $TemplatePath . 'home.php';
include($TemplatePath . 'layout.php');https://github.com/lincanbin/Carbon-Forum/blob/master/index.php
index.php这几十行代码我觉得并没有什么问题，这里面甚至主要还是SQL，易读也易懂，没感觉出有什么不好的地方了。
回复#1 @lincanbin :
你真的觉得自己的代码易读易懂？
真的易读易懂是
别人不用通读你的代码，也知道你的代码是干嘛的。
如果index.php上来就拼sql的代码也叫没有问题，那世界上就没有垃圾代码了。
不晓得你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化了他们也看不懂。
回复#3 @小明 :
你自己问问自己，说不要直接拼SQL，那么：
ORM除了把select，from等sql关键字和符号换成类的方法名外，跟SQL有区别吗？
如果这些SQL都看不懂，那实在也不可思议。
SQL是一门精心设计的声明性高级语言，已经被广泛使用接近30年，热度一直也没有下去，还不至于像你说的这样不堪。
回复#5 @lincanbin :
不可思议
回复#6 @小明 :
我也想问问你对于分页优化的一句SQL语句，写成50行ORM有什么看法？
回复#7 @lincanbin :
别扯啥orm，咱说的是基本的分层和封装
回复#9 @lincanbin :
这理解能力，也难怪代码写的跟面条一样。
回复#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检查、拿掉不需要的功能，只留下你会用到的程式模组。你不需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介于两者之间。
回复#10 @小明 :
不妨展示一下你的代码让我看看？
回复#13 @小明 :
我是来留名的
火钳刘明~~~~~~~~~~~
小明 挺可爱的
不辩不明
回复#16 @twor2 :
我不懂，说说观点，关键是这个代码排布，要是感觉不对，也列出一个感觉对的例子来分析分析呀，也不说的例子就说不好，哪知道说的什么，不利于进步
作为一个小白，作者的代码我真能看懂一些，但对于另外一种orm，我完全看不懂了
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检查、拿掉不需要的功能，只留下你会用到的程式模组。你不需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介于两者之间。