PHPフレームワーク環境でのSmartyの必要性

Question

PHP でシステムを開発する際ですが、恐らく何かしらのフレームワークを利用した場合は大半だと思います。そう言った時にテンプレートエンジンの Smarty を合わせて利用するかどうか意見が別れる時があります。

PHP でフレームワークが今ほど使われていなかった大昔は、素の PHP 実装 + Smarty で、ロジックとテンプレートを分離する流れがありました。
しかし、現在利用されるほとんどのフレームワークでは当たり前のように MVC の思想で構成されており、ロジックとテンプレートは初めから分離されています。

そう言った状況の中、Smarty を各フレームワークと連携してテンプレートエンジンとして利用する必要がどれほどあるのか、判断に苦しみます。

皆さんはどう考えるでしょうか？

shockatz · Accepted Answer

そもそも、CakeやZend Framework、Fuelなどほとんどのフレームワークが、設計コンセプトにおいて、Smartyの存在を無視している以上、あえて過去の遺物を引きずる必要はないです。
Smartyはテンプレートエンジンですらない、単なるタグパーサであり、モダン・フレームワークのアーキテクチャに合いません。
最新のMVCであるLaravelなどは、自前でBladeというテンプレートエンジンを装備していますし、WordpressのようなCNSでもSmartyは用なしです。

Smartyを採用したがるのは、開発をレガシーphpの手法に引き戻して、何とか仕事を自分たちの手の届く範囲に止めたい、オールドデベロッパーの悪アガキに思えます。

hue2011 · Answer

cakeだと、viewはE-R図を描いた上bakeで生成されてしまいますので、それを使わないと連携が危うくなります。
modelとの密接な連携も、フレームワークが囲い込んでいますし。

ただし、全くmodelと無関係なオブジェクトを使用するというのであれば、smartyは名前の通りスマートにできます。

Zendは書き方・書式がうるさい系統ですから、smartyを使うと、コードチェックに引っかかる可能性があります。

設計者の頭の中で、ここからはsmartyの領域だと区分けがきっちりできれば原則問題はないかと思います。
が、そんなに頭脳はクリアではないのです。

cakeが１から2になったときの混乱は今もひきずっていますが、smartyと一緒に使った場合、次に3ができて移行しようとしたときかなり混乱するようには思います。

goro123123123 · Answer

MVCになっていても搭載されているViewの機能が貧弱の場合があります。
その場合、Smartyを使った方が楽な場合があります。
(SmartyはViewに機能を絞って開発されている分、Viewとしての機能は高機能なので)

asuncion · Answer

Zend FrameworkとかCakePHPといった
MVCフレームワークを使うのであれば、
Smartyの必要性はあまりないような気がします。
素人の浅はかな考えですが…。

PHPフレームワーク環境でのSmartyの必要性

そもそも、CakeやZend Framework、Fuelなどほとんどのフレームワークが、設計コンセプトにおいて、Smartyの存在を無視している以上、あえて過去の遺物を引きずる必要はないです。

cakeだと、viewはE-R図を描いた上bakeで生成されてしまいますので、それを使わないと連携が危うくなります。

MVCになっていても搭載されているViewの機能が貧弱の場合があります。

Zend FrameworkとかCakePHPといった

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング