#PHP#Smarty 之类 的模板引擎 对比不使用模板引擎 具体有哪些优点?我有些疑问,请高手解答下
1.模板与代码分离,制作模板还需要再学习模板语言,增加了学习投入;2.就算美工与程序分离,程序员一样可以将需要调用的php的标签给美工啊;3.模板使用各种手段分离标签,对...
1.模板与代码分离,制作模板还需要再学习模板语言,增加了学习投入;
2.就算美工与程序分离,程序员一样可以将需要调用的php的标签给美工啊;
3.模板使用各种手段分离标签,对程序的运算增加了负担吧?
4.可以通过PHP实现缓存技术的,不一定需要模板引擎的吧?
5.必须使用模板引擎的情况有哪些呢?
请PHP业界高手给与详细解答一下吧,复制粘贴党请别凑热闹了吧,小弟是想好好学点真知识,看看是否很有必要掌握某一项模板引擎技术。
因为小弟准备深入框架研究,各类框架基本都和模板引擎存在或多或少的关系,我就是想要弄明白,模板引擎的真正意义,以及我的研究方向。 展开
2.就算美工与程序分离,程序员一样可以将需要调用的php的标签给美工啊;
3.模板使用各种手段分离标签,对程序的运算增加了负担吧?
4.可以通过PHP实现缓存技术的,不一定需要模板引擎的吧?
5.必须使用模板引擎的情况有哪些呢?
请PHP业界高手给与详细解答一下吧,复制粘贴党请别凑热闹了吧,小弟是想好好学点真知识,看看是否很有必要掌握某一项模板引擎技术。
因为小弟准备深入框架研究,各类框架基本都和模板引擎存在或多或少的关系,我就是想要弄明白,模板引擎的真正意义,以及我的研究方向。 展开
展开全部
1、smarty模板其实用不着学很多,会基本的 assign 和 display 就能解决基本的了
2、老实说很多美工都是女生(好比我们公司),他们是一点程序都不懂,连echo是什么都不知道
3、不会增加负担,会有专门的编译过程,编译一次后就不需要进行二次编译
4、这个是当然,但smarty的缓存技术已经很成熟了!其他的未必比得过
5、这个就不一定,看个人需求和公司要求
smarty本人其实也仅仅懂皮毛就OK了,老实说你要是真正的PHPer了,以后就好少单独用到smarty了,更深的MVC模式,TP框架等等才是真正花时间的~
2、老实说很多美工都是女生(好比我们公司),他们是一点程序都不懂,连echo是什么都不知道
3、不会增加负担,会有专门的编译过程,编译一次后就不需要进行二次编译
4、这个是当然,但smarty的缓存技术已经很成熟了!其他的未必比得过
5、这个就不一定,看个人需求和公司要求
smarty本人其实也仅仅懂皮毛就OK了,老实说你要是真正的PHPer了,以后就好少单独用到smarty了,更深的MVC模式,TP框架等等才是真正花时间的~
展开全部
我比较认同一种对框架的理解:框架是为了解决某类问题,根据经验和习惯制定的一种规则。
这句话有两个点,其一是“某类问题”,也就是说框架(Smarty 也可以理解成一种框架)不是万能的,它只适合特定的需求场景。其二,框架是“一种规则”,规则就意味着限制,有限制就会失去一部分自由就要付出代价。并且既然是规则那就要学习也就必然存在你所说的学习成本。付出成本的同时我们得到的是一种开发规范或者是实现某类特定需求时的一个相对固定(甚至是机械)的开发流程。
回答你的问题:
当项目代码量增加到一定量级的时候,业务逻辑和表现层的分离能够让代码的可维护性更强。
无数人都有过这样的想法:直接用PHP在html里写foreach跟用Smarty没什么差别。的确,如果你只是写<?php foreach?>是没什么差别,而且不考虑缓存的话效率也比用Smarty更高。但是,由于众所周知的各种原因,写着写着foreach里面就会出现一堆的业务逻辑甚至是数据库操作。一两个月之后自己再看代码都觉得天雷滚滚。smarty在这里扮演的就是一个约束者的角色,强制让你剥离业务逻辑。使代码可读,让团队中的每一个人都能够以相对低廉的代价阅读修改你写的代码。
至于是不是需要使用Smarty要根据具体项目而定。例如一个项目就俩页面加在一起不到1000行代码,我倾向于不用。
另外楼上也提到了团队中的前端开发人员只会HTML不懂PHP的问题,这个时候如果让他学习PHP或者学习Smarty那几个常用的标签哪个代价更大显而易见。
你提到的效率问题:
本质上是一种取舍,现在服务器的CPU和内存一般情况下不会成为瓶颈。对大多数公司而言加台服务器的成本要比请一个优秀的码字工低得多。特别是服务端开发,对程序的执行效率要求并不是很高。所以为了代码的可维护性以及开发的规范性牺牲一部分效率是可以被容忍的。另外你提到了缓存,用smarty可以很容易的实现表现层缓存。你用PHP本身的确能够以更小的代价实现这些缓存,甚至实现的更贴合你的需求。但是你会在每一个页面上都去实现这样的缓存机制吗?如果都做的话你必然要考虑代码复用,最终的结果只有两个:要么偷懒不做缓存,要么自己写一套化简的smarty。
说个题外话,既然在研究框架你应该会接触到ORM.例如JAVA里面的hibernate。用ORM就存在效率损失,所以绝大多数ORM都会通过各种方式对查询过程和查询结果进行优化、缓存。即使这样,在相当一部分案例中ORM的效率依然要低于直接执行写的靠谱的裸SQL。那么ORM存在还有价值吗?hibernate如今成为了实际上的业界标准,从一个侧面证明了ORM存在的合理性。在php中ORM这东西是否有存在的价值见仁见智,我个人倾向于不用。毕竟PHP的优势是小快灵,要是做的太像JAVA也就失去了它存在的价值。
至于什么情况下必须用smarty,如果是个人开发,答案是不存在这样的情况。至于团队开发,你的老板决定使用smarty的情况下你就必须要使用smarty。
最后给你一个建议:学习框架的同时,一定要把设计模式看懂、看透。当你积累了足够的项目经验。真正的理解了面向对象的设计思想,写代码的时候尽可能的去实现开闭原则的时候。你看框架的视角也就从仰视变成了俯视。
这句话有两个点,其一是“某类问题”,也就是说框架(Smarty 也可以理解成一种框架)不是万能的,它只适合特定的需求场景。其二,框架是“一种规则”,规则就意味着限制,有限制就会失去一部分自由就要付出代价。并且既然是规则那就要学习也就必然存在你所说的学习成本。付出成本的同时我们得到的是一种开发规范或者是实现某类特定需求时的一个相对固定(甚至是机械)的开发流程。
回答你的问题:
当项目代码量增加到一定量级的时候,业务逻辑和表现层的分离能够让代码的可维护性更强。
无数人都有过这样的想法:直接用PHP在html里写foreach跟用Smarty没什么差别。的确,如果你只是写<?php foreach?>是没什么差别,而且不考虑缓存的话效率也比用Smarty更高。但是,由于众所周知的各种原因,写着写着foreach里面就会出现一堆的业务逻辑甚至是数据库操作。一两个月之后自己再看代码都觉得天雷滚滚。smarty在这里扮演的就是一个约束者的角色,强制让你剥离业务逻辑。使代码可读,让团队中的每一个人都能够以相对低廉的代价阅读修改你写的代码。
至于是不是需要使用Smarty要根据具体项目而定。例如一个项目就俩页面加在一起不到1000行代码,我倾向于不用。
另外楼上也提到了团队中的前端开发人员只会HTML不懂PHP的问题,这个时候如果让他学习PHP或者学习Smarty那几个常用的标签哪个代价更大显而易见。
你提到的效率问题:
本质上是一种取舍,现在服务器的CPU和内存一般情况下不会成为瓶颈。对大多数公司而言加台服务器的成本要比请一个优秀的码字工低得多。特别是服务端开发,对程序的执行效率要求并不是很高。所以为了代码的可维护性以及开发的规范性牺牲一部分效率是可以被容忍的。另外你提到了缓存,用smarty可以很容易的实现表现层缓存。你用PHP本身的确能够以更小的代价实现这些缓存,甚至实现的更贴合你的需求。但是你会在每一个页面上都去实现这样的缓存机制吗?如果都做的话你必然要考虑代码复用,最终的结果只有两个:要么偷懒不做缓存,要么自己写一套化简的smarty。
说个题外话,既然在研究框架你应该会接触到ORM.例如JAVA里面的hibernate。用ORM就存在效率损失,所以绝大多数ORM都会通过各种方式对查询过程和查询结果进行优化、缓存。即使这样,在相当一部分案例中ORM的效率依然要低于直接执行写的靠谱的裸SQL。那么ORM存在还有价值吗?hibernate如今成为了实际上的业界标准,从一个侧面证明了ORM存在的合理性。在php中ORM这东西是否有存在的价值见仁见智,我个人倾向于不用。毕竟PHP的优势是小快灵,要是做的太像JAVA也就失去了它存在的价值。
至于什么情况下必须用smarty,如果是个人开发,答案是不存在这样的情况。至于团队开发,你的老板决定使用smarty的情况下你就必须要使用smarty。
最后给你一个建议:学习框架的同时,一定要把设计模式看懂、看透。当你积累了足够的项目经验。真正的理解了面向对象的设计思想,写代码的时候尽可能的去实现开闭原则的时候。你看框架的视角也就从仰视变成了俯视。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
主要是smarty模板能是php代码和html代码分开,这样php程序员和网站的美工人员就可以各司其职,更方便网站的维护。这就是我理解的使用smarty模板的真正意义!!!满意吗???
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
smarty 的作用就是使 前后台分离 开发人员分工明确 互不影响
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询