PHP艰难回归正统

xgyxgy

我觉得有些模板不太必要。其实还是那句话，关键是看写程序的那个人而已。如果水平高，写得好的话，不用模板比用模板写出来的程序更容易读，也更容易维护。并不是说你用了模板就一定是MVC模式，不用就一定不是。这些都要看写程序的个人水平而已。对于面向对象方面嘛，我觉得一定要习惯用了。

夜猫子

如果我做的程序需要像论坛那样可以换皮肤，我肯定会用模板解决。
至于用了模板真的是不是可以做到逻辑和显示分离，开发人员和页面人员分离，还看设计水平，总之模板还是个不错的东西，只看会不会用，有没有用过火。

mirnshi

原帖由 "longnetpro" 发表：
颍?愕乃枷刖椭换嵛??怂?笥摇?

总之楼主的那篇文章中，我认为对人有一些误导，使人盲目地从一个极端走到另一个极端，这都不是可取的。因此特地来发表一些个人观点。

当然，我的观点中可能也有不足，希望合?.........

99年,我就做到了用c++开发cgi程序，页面和程序分离，也就是通常的模板技术。这也不是什么高深的技术。采用模板后，开发的效率会很高。页面和程序各自负责，影响降到了最低。今年年初，用.net开发，照搬同样分离。

mirnshi

按照你的意思，恐怕只有.net目前可以做到这点，一旦进入表现层后，就由界面的表现层自动处理了（如表格和数据源绑定后就可以完成翻页功能，程序自身不需要处理翻页）。大家通常意义的理解是模板可以有一个普通的客户，不必要具备程序设计能力就可以改变程序的表现风格。而要做到2个逻辑上的分离，不知道这个模板在实际应用中该由谁来实际处理？
个人觉得，采用模板以及如何使用模板有点涉及到方法论，提高效率降低强度，我想这才是模板的初衷，就如同设计模式一样。

mirnshi

[quote]原帖由 "longnetpro"]了解楼上说的，这的确是个问题。不过，上面不是有的朋友及我都提出过预编译模板的观点吗？其实那个就是为了解决这个矛盾的一个折中之举。它甚至对任何语言都适用，只是多一个或是少一个中间步骤而已。这个思路抛开了..........[/quote 发表：

其实，我个人觉得，将模板和程序分离，有一个非常重要的理由是解放程序员。程序的亲和力很多情况下取决于界面的美观度，而每个人的审美观是不同的。不同的客户理解就更不同了。在实际情况中，如果界面和程序完全分离，客户可以按照自己的意愿随意修改模板满足他的需求。对于b/s结构来说，在页面上修改点东西，增加一个连接，这种要求很合理。但是这些小小的要求都要程序员重新编译，代价就高了点。在一个产品/系统要占领市场取悦客户时，这很重要。不过说到这，有点跑题了。

mirnshi

其实,我们讨论的是模板的问题. 从整个帖子看来主要分2种观点:
1. 模板是为了将表现层和逻辑层分开
2. 模板是为了将页面和程序分开

对于观点1, 也就是模板是为了将表现层和逻辑层分开. 程序员可以较少地参与页面的表现.
上面的帖子中提到了模板引擎--负责页面处理. 那么模板引擎应该也是一些程序处理的. 只不过
程序员认为模板引擎可以处理好页面的表现. 从面向对象的角度来说，数据封装得更彻底。从这点
出发, 由美工作出来的页面应该和模板引擎紧密关联的. 美工设计完界面后, 一定有一个人对于
程序语言和html都有所了解的人检查这个页面.也就是说，这个页面中含有动态的控制元素很多，
一个没有基础的人在很短的时间内不可能辨认正确与否，如果不审核，就有可能产生运行错误。

对于观点2，也就是模板是为了将页面和程序分开。程序员同样可以较少地参与页面的表现. 页面虽然
分离的，但程序中同样存在页面处理的程序（函数），但和上面有所区别的是，美工的页面被当作
纯粹的数据而被处理。从面向对象的角度来说，页面表现封装得更彻底。这种页面中，动态的控制元素
很少，一个没有基础的人在很短的时间内就可以学会。对于这种方式，不会产生运行错误，只会产生
逻辑显示错误，也就是从安全角度，会得到加强。

每种观点只是侧重点不同而已。在实际工作中，就可以看出每种方法的优点和缺点。

yb0312

php好像对面向对象方法支持不够好噢