トップページ⇒php
1001コメント257KB

[PHP]フレームワークについて語るｽﾚ4[総合]

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2006/07/01(土) 07:35:07ID:Pg6bOKC2
前スレ
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/

[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/

よく話題になるフレームワーク

■Zend Framewoek
http://framework.zend.com/
http://framework.zend.com/manual/ja/ （日本語マニュアル）

■symfony
http://www.symfony-project.com/

■[ 日本発 ] Ethna
http://ethna.jp/
0664nobodyさん2006/09/02(土) 02:10:01ID:???
Zendは現状ライブラリ集だから
MVCに別のFWを使わないといけないじゃん。
MVCに特化した超軽FWがあれば…
0665nobodyさん2006/09/02(土) 02:23:38ID:???
>>663
＞PHPはフレームワーク内ですべてを完結してる分、開発停止になったときのリスクが大きい。
やれやれ…
0666nobodyさん2006/09/02(土) 02:27:49ID:???
>>664
いや、ライブラリ集ってのはありえんのでは・・
皮肉で言うのはまだわかるんだけど
ZFの現状の難点はModelがまだまだなのと
ZFormあたりが未完成って意味でViewもちと甘いってとこじゃ
0667nobodyさん2006/09/02(土) 02:29:44ID:???
いや事実だから。
PHPって結局作り捨てのサイトになりがちなんだけど、マイナーなフレームワークを使うくらいなら、
シンプルにレイヤー分けだけした方がマシと思うね。
smartyとPEAR DBみたいなDB集約クラス使えば、基本的な分離が出来るし、それで十分ば場合も多い。
0668nobodyさん2006/09/02(土) 02:32:53ID:???
十分ば場合も多いよね。うん。たしかに十分ば場合も多い。
お前らも十分ば場合も多いと思うよね？
0669nobodyさん2006/09/02(土) 02:41:50ID:???
いや、僕はあまり十分ば場合が多いとは、言えないと思う。
0670nobodyさん2006/09/02(土) 02:47:41ID:???
PHPにはライブラリがないのが最大の問題なんだよね。
PEARの品質の悪さを言ってもあるだけまだマシで、PHP5になったらもうどうしようもなくなる。
結果、各フレームワークで自前で実装するけど、当然、フレームワークごとにAPIはバラバラ。
いちいち覚えなおす羽目になる。
このフレームワークのバリデータは使いづらいから改造しよう、描画クラスに機能を追加しようって、
そんなサイトを引き継がされる次のプログラマーの悲惨さったらない。
0671nobodyさん2006/09/02(土) 02:48:33ID:???
PHPは元々WEB向けの、直書きが物凄く楽な言語だから
FWで全部用意するよりもある程度使い手に任せる方が
PHPっぽいと思うんだな。
ZF恐らくこうした感覚のもとで組まれてると思う。
PHPのFWが乱立する状況も単純に真似し易いって事が
あるんじゃないかなーと。
0672nobodyさん2006/09/02(土) 02:59:32ID:???
>>670
フレームワークごとにバラバラでも、ライブラリやフレームワーク自体、
何かしらのパクりなので、さして覚え直すというほどの手間はないけどね。
変にかぶこうとせず素直にパクってる分、多言語とかへの移行も容易だし。


>>671
>FWで全部用意するよりもある程度使い手に任せる方が
>PHPっぽいと思うんだな。
そのPHPっぽさに限界を感じて、フレームワークが求められ、
そして多数生まれているのが現状です。
0673nobodyさん2006/09/02(土) 03:09:23ID:???
フレームワークって個人でも作るのは簡単なんだよな。だから誰でも作りたがる。
しかし、要望に応えてあれこれ追加してるうちに、忙しいのにこんなの無料でやってられるかってディスコンになる。
まして、CPANだとかJakartaレベルのライブラリを個人で作れるわけもなく、じゃあ誰が音頭を取るかといえば、ZEND以外に選択肢はない。
0674nobodyさん2006/09/02(土) 03:36:11ID:???
PHPによるMVC設計の実演サンプルが大量に転がってる状態だから
便利っちゃ便利だけどね
0675nobodyさん2006/09/02(土) 03:44:43ID:???
symfonyは会社でやってるから
個人製よりはずっと乗るリスク低いと思う
0676nobodyさん2006/09/02(土) 03:54:12ID:???
その点Cakeはやや大学生ノリっぽさが漂うな
運営はどうなってるんだろ
0677nobodyさん2006/09/02(土) 05:02:02ID:???
ZFっていちおうController周りはほぼ完成してるよね。
Viewもアクションの中からテンプレート内で使う変数にデータを代入できて、アクションの中からテンプレート名を指定できて、ヘルパーも汎用的な意味では使えるよね。
>>666によるとZFormが未完成ってのもあるらしいけど。
Modelは何も実体がないけど、Mojaviのときも何もなかったから、どういう機能が実現しえるのかよくわからん。

SymfonyとかCakeとかEthnaとか使ってる人に聞きたいんだけど、ZFのMVCで足りないものとか欲しい機能ってどんなものがあるの？
0678nobodyさん2006/09/02(土) 09:35:15ID:???
>>677
MVCとかそういうレベルの話じゃない。
0679nobodyさん2006/09/02(土) 09:39:25ID:???
>>677
＞ZFっていちおうController周りはほぼ完成してるよね。
あなたの目は節穴ですか？

This section is not yet complete. It is under heavy construction and is subject to change.

この節は未完成です。現在作成中であり、今後変わる可能性があります。
0680nobodyさん2006/09/02(土) 10:03:34ID:???
普通に使えるよZFのController周り
scaffoldがあってコマンド一発でCRUD出来ないと
未完成だと思う人達には未完成なんだろうが

>>678
じゃあどういうレベルの話なんだ？

>>679
おまえこそ実際に使ってみてそれ言ってるの？
その「未完成」がまだ使い物にならないってことか
だいたい出来てるけどさらによくなりますってことか
一度サンプルでも書いてみりゃすぐにわかるだろうに
06816772006/09/02(土) 11:34:02ID:???
>>680
フォローサンクス！
みんなRoRのscaffoldみたいなのを求めてる部分もあるみたいだね。
ある意味それも今ZFに足りない機能の一つなんだろうな。

あと、ZFのコントローラが完成か未完成かってのは置いといて、モデルやビューに欲しい機能もまだあるのかな？
rubyだとメタプログラミング的な方法でモデルにある程度一貫性持たせられてるけど、phpだと結局自分なりにモデル作るしかないし、それで十分かとも思う。
value object的なクラスはstdclass継承とか。

まあヘルパはもうちょいバラエティほしいと思ったりもするけど。
0682nobodyさん2006/09/02(土) 12:43:08ID:???
ZFでひどすぎるのはView。
素のPHPと大差ねーよ。
0683nobodyさん2006/09/02(土) 15:37:25ID:fxJyUNCr
>>686
変数に$this->をつけるのが面倒
0684nobodyさん2006/09/02(土) 17:43:22ID:???
オブジェクト関係の処理を高速化するための方法
http://www.phppro.jp/news/58

ってか、オブジェクトおせえええええ
オブジェクト指向が糞ってことは
どう見てもPHPフレームワーク終了です
ありがとうございました
0685nobodyさん2006/09/02(土) 18:19:56ID:???
下手な釣りですねぇ・・・
0686nobodyさん2006/09/02(土) 18:21:35ID:???
>>684
OOPは実行速度が遅いのは、保守性なんかを優先した結果であり、
遅いからといって一概に使い物にならないとは判断できない
0687nobodyさん2006/09/02(土) 18:26:11ID:???
2倍どころじゃなく10倍くらい遅いんだよ？
0688nobodyさん2006/09/02(土) 18:38:22ID:???
OOP部分の処理は糞遅いが、コンパイル時間やファイル処理時間などを考えて、全体的に見れば 1.5 ～ 3 倍になる。
その程度なら鯖を増やせばなんとかなる。
0689nobodyさん2006/09/02(土) 19:04:38ID:???
>>682
View周りに関しておすすめなFWを教えておくれ。
良かったら真似したい。
0690nobodyさん2006/09/02(土) 19:18:07ID:???
>682
Viewに何を期待しているの?
0691nobodyさん2006/09/02(土) 20:19:58ID:???
>>689
symfony
0692nobodyさん2006/09/02(土) 20:24:45ID:???
オブジェクトを使わないフレームワークってありますか？
0693nobodyさん2006/09/02(土) 20:27:36ID:???
>>687
記事にはそれを改善する手段が書かれている気がするけど？
0694nobodyさん2006/09/02(土) 20:29:28ID:???
symfonyもViewはそんな変わらないんじゃないのか？
ヘルパが充実してんだっけ
フォローおながい
0695nobodyさん2006/09/02(土) 20:31:45ID:???
8. 引数が1つで中での処理を全くしない関数を呼び出した場合では、
ローカル変数をインクリメントした場合の7～8倍の時間がかかりました。
同じようなメソッドを用意した場合は、約15倍ほどの時間がかかっています。

メソッド呼び出し→15倍遅い
$this->getContext()->getRequest()->getParameterHolder()->getHoge()
とかやったらどうなるんだ…
やりまくってるわけだが…
0696nobodyさん2006/09/02(土) 20:34:38ID:???
>>694
symfonyのviewは
すぺしゃる且つ
えくせれんとですよ。
0697nobodyさん2006/09/02(土) 20:37:21ID:???
>>692
https://sourceforge.net/project/showfiles.php?group_id=142757

>>695
$this->getContext() とか
$this->getContext()->getRequest() とか
が複数あるならローカル変数に代入。
1つしかないなら改善の余地がないから、フレームワークによってもたらされる利点と比較検討して判断。
0698nobodyさん2006/09/02(土) 20:43:50ID:???
>>691
さんく　みてみる。
0699nobodyさん2006/09/02(土) 20:45:47ID:???
>>697
何だこの恐ろしくシンプルなフレームワークはw
0700nobodyさん2006/09/02(土) 20:45:54ID:???
そういうチューニングって、ひとまず完成してからやらないとスパゲッティ化が進行してひどいことになるよね。
変数への代入やメソッド呼び出しが速くなったたところで全体から見れば微々たる差ということもよくあるし。
重い処理を速くするにはアルゴリズムの見直し、Cでモジュール作成、ハードウェアを増強などの根本的な改善が必要。
0701nobodyさん2006/09/02(土) 20:48:06ID:???
extremely simpleって書いてるけど
これはフレームワークなのか微妙だなぁ
0702nobodyさん2006/09/02(土) 20:55:16ID:???
>>701
十分フレームワークだと思う
0703nobodyさん2006/09/02(土) 20:56:15ID:???
PHPの実装が糞すぎるｗｗｗ
0704nobodyさん2006/09/02(土) 20:59:53ID:???
PHP5になって
高速化したと思ってたから
OOが未だにそんなに遅かったことがショックです（＞＜）
0705nobodyさん2006/09/02(土) 21:12:18ID:???
何倍何倍とか言ってるけどprintよりechoが速いとか
その程度のレベルの話
釣られすぎ
0706nobodyさん2006/09/02(土) 22:09:55ID:???
GETパラメータを1個受け取って、それをキーにしてDBから10件データ取得して、HTMLのTABLEタグに入れて表示する。
そういうことをするならPHPが一番速いよ。学習スピードも実行速度も。
難しいことをしようとすると、アラが出てくるけど。
0707nobodyさん2006/09/02(土) 22:23:30ID:???
良くも悪くもインスタント、それがPHP
0708nobodyさん2006/09/02(土) 22:25:30ID:???
staticなクラスの関数も遅いんか？
0709nobodyさん2006/09/02(土) 22:36:04ID:???
OOPで～すると～倍って、PHPの設計の問題じゃないっしょ
0710nobodyさん2006/09/02(土) 22:43:03ID:18r2NV7f
確かに…・。
ローカル変数のインクリメントと
プロパティーのインクリメント、マシン語で組んでも何倍か遅くなるよな。
しょーもない実験したシルバートン氏ね。
0711nobodyさん2006/09/02(土) 22:54:11ID:???
しかも高速化のために継承クラスのメソッド呼ぶとかありえねーから。
OOPを基礎から勉強しろや＞シルバートン
0712nobodyさん2006/09/02(土) 23:03:07ID:???
当たり前のこと言っただけのシルバートン殴りたい
0713nobodyさん2006/09/02(土) 23:07:06ID:???
まあ、最近、はてなとかmixiとかがウェブサーバ（アプリケーションサーバ）はクラスタリングさせればいい、みたいな記事書いてるけど、
あれははてなやmixiみたいな予算も開発者リソースも十分あるところでの話だからね。
現実にはウェブサーバ1台+DBサーバ1台、もしくはウェブサーバ兼DBサーバ1台でやりくりしないといけない案件も多い。
そういう時に「フレームワーク使ってるんだから遅いのは仕方ない」では済ませられない。
0714nobodyさん2006/09/02(土) 23:07:40ID:???
いやまぁ啓発的な意味では良い仕事したんじゃね？＞しるばーとん
もちろん期せずしてという感じだけど
PHPのコミュニティは俺含めOOPの熟練度が低いのが多い
0715nobodyさん2006/09/02(土) 23:08:19ID:???
シルバートンっていうかphpproの記事に釣られて
大袈裟に捉えてる脊髄反応してるやつがアフォなだけだろ
OOPの考え方自体速度とメモリは多少犠牲されるもんだし
その上での細かいチューニングってだけの記事なのに

てかphpproちょこちょこ見たけど酷いね
0716nobodyさん2006/09/02(土) 23:09:25ID:fxJyUNCr
ちょっと待て！全員釣られてるぞ！
0717nobodyさん2006/09/02(土) 23:12:23ID:???
重箱の隅チューニング記事でここまで盛り上がるFWスレ
0718nobodyさん2006/09/02(土) 23:17:29ID:???
>>715
http://www.phppro.jp/qa/detail.php?id=146
これﾋﾄﾞｽｗｗｗｗ
何の質問だよ
0719nobodyさん2006/09/02(土) 23:19:08ID:???
原文の記事のコメントで、突っ込みの形で結構興味深いコメント付いてるし
結果的にはイイ釣りしたと思う。
Interestingly, the speed of a method call with no parameters was almost exactly the speed of a function call with one parameter.
This is to be expected because the object is a hidden parameter to the method, which becomes the $this variable.
0720nobodyさん2006/09/02(土) 23:19:18ID:???
>>715
どこかでも書かれてたけど「PHPのプロ」のためのサイトじゃなくて
「PHPのプロになりたい人」のためのサイトになっちゃったのには失望した
0721nobodyさん2006/09/02(土) 23:21:52ID:???
シルバー㌧のフィッシャーマンとしての才能に嫉妬
0722nobodyさん2006/09/03(日) 01:30:32ID:1+qDONPA
速度求めるならPHPは使わないって感じじゃん？
まあ、WEBアプリで処理が遅くなるのはDB周りだから、
そこらへん気をつければ何でもいいと思うが。
0723nobodyさん2006/09/03(日) 02:51:24ID:???
>>719
だからpythonのメソッドは常に第一引数にself（phpでいう$this）が必要なのか
0724nobodyさん2006/09/03(日) 03:07:34ID:???
>>722
逆。DB設計をしっかりしていれば、速度の差はアプリ側で出てくる。
0725nobodyさん2006/09/03(日) 03:11:07ID:???
>>713
＞現実にはウェブサーバ1台+DBサーバ1台、もしくはウェブサーバ兼DBサーバ1台でやりくりしないといけない案件も多い。
そのレベルでやりくりしなきゃいけないレベルなら、まずフレームワークで体感するほどの遅さは出ない。
よほど酷い作り方してなきゃね。

トラフィックが増えてきたら、当然それに伴って収入も増えるだろうから、サーバ増強もできるし、問題なし。
逆にトラフィックが増えてるのに、それに見合った収入が来ないなら、運営や企画側の問題。
0726nobodyさん2006/09/03(日) 04:28:38ID:???
>>725
体感できないことはないじゃない？
0727nobodyさん2006/09/03(日) 11:17:41ID:???
トラフィックが上がってきたのにサーバ増強をしたくない側の因縁の付け所として
フレームワークによるパフォーマンスロスとかがしたり顔で指摘されたりするんじゃないか？

そんなくだらねー内容のミーティングやる人件費で代わりに少しでもメモリ増やせ！と
言いたい人は多かろう……ｗ
0728nobodyさん2006/09/03(日) 14:24:17ID:???
>>725
>>727

耳が痛いですｗ

アクティブユーザーが5000人のサービスが共用サーバってどうなんでしょうかね？
0729nobodyさん2006/09/03(日) 15:35:20ID:rN8m3138
結局、全員釣られたわけか・・・ｗ
0730nobodyさん2006/09/03(日) 15:44:07ID:???
>>727
まぁ、ミーティング意外にも、フレームワークはずして開発効率下げれば、
結果的にコストはかさむわけだしね。

そういうおかしな所とは、さっさと縁を切るのが吉。


>>728
…デイリーユニークではなくて…？
0731nobodyさん2006/09/03(日) 15:46:24ID:???
>>726
よほどサーバが貧弱だったり、hello Worldするだけなら体感できるだろうね。
0732nobodyさん2006/09/03(日) 16:09:37ID:???
>>728
＞アクティブユーザーが5000人のサービスが共用サーバってどうなんでしょうかね

まあ、どういうサービスなのかにもよるよね。
たとえばオンラインRPGなら5000人は無理だろうし、
たとえばmixiみたいな（軽い？）アプリなら、１台で１万人くらいの
アクティブユーザーを抱えても大丈夫なんジャマイカ？
0733nobodyさん2006/09/03(日) 16:14:57ID:???
>>732
彼は共用サーバと言っていますが
0734nobodyさん2006/09/03(日) 16:58:32ID:???
メモリなんて安いんだから積めるだけ積めばいいんだよな。
どれだけ積もうが維持費は変わらないし。
フレームワークの遅さを気にしたり、
ましてシルバートンみたいなTIPSにこだわるのはナンセンス。
0735nobodyさん2006/09/03(日) 17:46:21ID:???
zend_view_smartyって落とせなくない？
07367322006/09/03(日) 17:53:00ID:???
>>733
あ、ごめん、勘違いした。

>>734
メモリ増設で増設費は当然かかるにしても、なぜか維持費まで取るレン鯖屋は氏ねばいいのにね・・・
なぜメモリを増やしただけで毎月数千円も取るのかと小一時間（ｒｙ
0737nobodyさん2006/09/03(日) 18:17:07ID:???
>>736
いやそれはリアルに問い詰めた方がいいと思うぜｗ
0738nobodyさん2006/09/03(日) 18:22:42ID:???
>>736
それはそういう鯖屋なんじゃないのか？
一見、プラン的に見たら他社と比べて安いけれど、実運用の中でちまちまコストがかかって
結局トータルコスト的に、他社と同じか以上になっちまう
0739nobodyさん2006/09/03(日) 21:34:04ID:???
>>737
そういう鯖屋って、けっこう多いよ。
たとえば「使えるねっと」　http://www.tsukaeru.net/ps_options.php
512MBメモリ増設したら、初期費とは別に「月額1980円」だって。
つまり年間24000円が、通常の鯖代とは「別に」、永久に上乗せされ続ける。
１GB増設だったら、なんとメモリ増設代だけで年間48000円！！

もうね、アホかと。
>>738も書いてるように、一見すると安く見せかけておいて、
実用的に使おうと思ったら結局トータルで異常な高コストになるという
典型的なボリ・パターン。
0740nobodyさん2006/09/03(日) 21:51:56ID:???
>>739
使えねええええw
たった512Mで2000円てありえん
0741nobodyさん2006/09/03(日) 23:40:20ID:???
>>739
しかも初期プランでメモリ容量の選択の余地が無いってのが終わってるな。
0742nobodyさん2006/09/03(日) 23:44:46ID:???
名前のわりに使えないな
0743nobodyさん2006/09/04(月) 02:29:05ID:snFu/sQO
>>742 だれがu(ry
0744nobodyさん2006/09/04(月) 03:27:14ID:???
>>743　木魚が言った
0745nobodyさん2006/09/04(月) 08:01:02ID:???
>>
0746nobodyさん2006/09/04(月) 12:36:43ID:???
携帯・PC両用のサイトを作るならどれがおすすめですか？
0747nobodyさん2006/09/04(月) 12:48:19ID:???
>>746
あれがおすすめです。
0748nobodyさん2006/09/04(月) 16:48:13ID:???
[専用]使えるねっとをもっと使いたおすで002[VPS]
http://pc8.2ch.net/test/read.cgi/hosting/1146455766/
使えないぞ！！「使えるNET」　part2
http://pc8.2ch.net/test/read.cgi/hosting/1067352020/
0749nobodyさん2006/09/04(月) 18:28:16ID:jumGdf4H
>>746
Rails
0750nobodyさん2006/09/04(月) 18:30:50ID:vvZvdfF9
>>746
ZF
0751nobodyさん2006/09/04(月) 19:19:12ID:???
あのー、ZF は、yaml　とか変なの使わなくていいですか？
0752nobodyさん2006/09/04(月) 19:24:17ID:???
ymlの代わりにiniとarrayとxml使えるけど
普通のFWより敷居が高いよ
0753nobodyさん2006/09/04(月) 19:44:53ID:???
なんでZend_ConfigにyamlがねーんだろうなPEARにもねーし
spycで問題ないけどさ
なんかこういう時にPHPっていつも乗り遅れてる感感じちゃうな
0754nobodyさん2006/09/04(月) 19:48:39ID:???
ま、spycで問題ないから、いいんじゃない。
0755nobodyさん2006/09/04(月) 19:56:22ID:???
ZFは複数形式を想定した構造だから
yaml対応は楽勝でしょ

個人的にはパーサが必要な形式は
まとめて結構ですって感じだけど・・・
0756nobodyさん2006/09/04(月) 20:44:51ID:???
xmlで設定とかありえねー。
PHPはarrayがベスト。動的に対応可能だし。
0757nobodyさん2006/09/04(月) 20:49:28ID:???
yamlのがいいよ
ただでさえPHPはarray()って書くのめんどくさいのに
0758nobodyさん2006/09/04(月) 20:52:16ID:???
xmlはあかんかったな。
機械的に処理できて、人間にも読みやすいというのが売りだったが、
処理速度は遅くなるし、人間が扱うには冗長で使いにくかった。
0759nobodyさん2006/09/04(月) 21:41:31ID:???
まあ、設定書くのにXMLは使いたくないな…。
とはいえ、Java界隈だと普通だったりするけどな。
0760nobodyさん2006/09/04(月) 21:42:09ID:???
まぁどれも適材適所だから・・・
yamlもsymfonyみたいな形なら使いたくないし
0761nobodyさん2006/09/04(月) 21:44:28ID:???
(#ﾟДﾟ) symfonyの悪口言うな！
0762nobodyさん2006/09/04(月) 21:47:07ID:???
>>761 ごめにょ
0763nobodyさん2006/09/04(月) 22:01:59ID:???
>>761
http://pc8.2ch.net/test/read.cgi/php/1151937402/
こっち行ってろタコ
■ このスレッドは過去ログ倉庫に格納されています