トップページ⇒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/
0615nobodyさん2006/08/30(水) 13:19:37ID:???
>>614
正確にはBBSではないのかも知れなかったです。
BBSだけのサイトではなく今だとどんなサイトでも掲示板、コメントシステムはあると
思うのですけど簡単そうでBBSって結構奥が深いと思うのです。

認証、スパム対策、二重投稿防止、BBコード、WYSIWYG?などなど…
そういうのがライブラリ的でもいいのであるとみんな幸せになれるかなと

#phpBBから取って来いと言われればそれまでですが、切り出しやすくなっているかどうか…
0616nobodyさん2006/08/30(水) 14:27:16ID:9+dNEl7v
MojaviからZend Frameworkへ移行しようと思う。
理由はなんかかんだで主流になると思牛。
0617nobodyさん2006/08/30(水) 14:30:41ID:9+dNEl7v
MojaviからZend Frameworkへ移行というか学習だな。ハハ
0618nobodyさん2006/08/30(水) 14:57:41ID:???
>>615を見て勉強がてら作ってみようかと思ったんだけどViewが嫌杉なんですけど。。
これってやっぱSmarty使えないんか？
0619nobodyさん2006/08/30(水) 19:36:22ID:???
そもそもZend_View自体取り外し可能
Smartyをそのまま組み込むもよし
自前のViewでやるもよし
Zend_Viewを継承する形でSmartyを組み込んでもよし
それがZFスタイルです
0620nobodyさん2006/08/30(水) 19:42:22ID:???
現状MVCはあってないようなもの。
コンポーネントは汎用というよりは
機能に特化されている。
コンポーネントで提供されてる機能を使う状況じゃなければ
ZFを使う必然性がないぽ。
0621nobodyさん2006/08/30(水) 20:28:15ID:???
>>620
その通りだけど逆にそれぞれ機能に特化してるから
FW全体で見ると汎用的だと思うぜ
コンポーネントで使いたいモノだけロードしてすぐに使える
FW内のあの機能だけ個別で使いたい、っていうのは
symfonyやcakeじゃやりにくいだろうしね、用途次第
あとCはよくできてるよMVはグダグダだけどな
0622nobodyさん2006/08/30(水) 21:42:04ID:???
フレームワークで出来ることなんてだいたいPEARで出来るじゃん
骨折り損乙ｗｗｗｗ
0623nobodyさん2006/08/30(水) 22:14:10ID:???
>>622
その発想は無かったわ
0624nobodyさん2006/08/30(水) 22:34:23ID:???
フレームワークブーム終了
0625nobodyさん2006/08/30(水) 23:55:49ID:???
で、PEARで出来ることはだいたい自前のクラスや関数で出来るんだけどねｗｗｗ
0626nobodyさん2006/08/30(水) 23:59:41ID:???
自前の関数やクラスで出来ることはぜんぶCで(ry
Cで出来ることは全部アセ(ry

って展開を前にもこのスレで見た気がする
0627nobodyさん2006/08/30(水) 23:59:45ID:???
フレームワーク＝車輪の再発明ってことでおｋ？
0628nobodyさん2006/08/31(木) 02:06:16ID:???
つーかZFが足りない足りない言ってる奴は具体的に何が足りないと思ってる？
pluginってやつでほぼ全箇所にフィルタ差し込めるし、全コンポーネントが継承によるカスタマイズしやすいように（クラス名は長ったらしいが）工夫されてると思う。
もちろんカスタマイズしなくても、デフォルトでそこそこ文句のない動作するしね。

>>627
いままでWebアプリ自体が車輪の再発明になりがちな部分が多かったので、それを減らすのがフレームワークの目的の一つ。
0629nobodyさん2006/08/31(木) 02:15:27ID:???
>>628
＞もちろんカスタマイズしなくても、デフォルトでそこそこ文句のない動作するしね。
Zend_DB_Tableまともにさわったことありますか？
そこそこどころじゃないよ。勘弁してよ全く。
0630nobodyさん2006/08/31(木) 02:17:14ID:???
未だにフレームワークの必要不必要語ってるところが、PHPユーザのレベルを物語ってるよなぁ
0631nobodyさん2006/08/31(木) 02:19:51ID:hGrqENCK
ZFは問題ありません。以上
0632nobodyさん2006/08/31(木) 02:44:06ID:???
>>630
JAVAなどは「ガチガチ」の言語だから、どうしてもフレームワークがないと
使い物にならないってだけ。

PHPはFWが無くても使える自由度の高さが売りなんだから、
どっちがいいとか悪いとかいう問題じゃない。

FWが必要不可欠という考え方は硬直し過ぎ。
0633nobodyさん2006/08/31(木) 02:53:03ID:???
>>629
DBとかはフレームワーク的な部分じゃなくてライブラリ的な部分じゃね？
まあたしかにZFのDBまわりは期待した動作しなかったりバグがまだ多いっぽいけど、逆に言うとPDOとか生で使っても問題ないように疎結合な作りになってるのもZFの売りなんじゃないかと。
0634nobodyさん2006/08/31(木) 02:58:55ID:???
別にJavaだってフレームワークなしでもかまわないと思うけど。
0635nobodyさん2006/08/31(木) 03:06:38ID:???
Understanding the Zend Framework, Part 2: Model-View-Controller and adding a database
http://www-128.ibm.com/developerworks/edu/os-dw-os-php-zend2.html

このページがどうも中途半端な内容なんだけどちゃんと見れた人いる？
ユーザ登録してもリンクが切れてて続きが見れない状態になってる気がする
ちなみにPart1、4、6、7は普通に読める
http://www.ibm.com/developerworks/opensource/library/os-php-zend1/
0636nobodyさん2006/08/31(木) 03:06:41ID:???
FWだのライブラリだの、
他人が作ったものを組み込めば組み込むほど、
トラブルやエラーが発生した時に
原因の発見や対処が難しく、面倒になっていく。
0637nobodyさん2006/08/31(木) 03:25:34ID:???
>>636
スキルと管理能力の無さを言い訳してるだけだろ
0638nobodyさん2006/08/31(木) 04:57:40ID:???
>>637
そうですねあなたはすごいですがんばってください
0639nobodyさん2006/08/31(木) 10:12:11ID:???
>>637
オープンソースを使うときは、瑕疵責任の範囲を、自分の作った所だけに限定するようにしている。

他人のコードにバグがあったら、そこまでは面倒みない。
（面倒見るとしたら別料金）

契約時に、それを飲んでもらえない相手は受注しない。
0640nobodyさん2006/08/31(木) 13:39:43ID:???
他人の書いたものを使うときはいつだって、その便利な機能と
思い通りに動かない場合のリスクと、自分で書く手間とのバランスだ。
0641nobodyさん2006/08/31(木) 17:02:06ID:???
>>618
? BBSのライブラリを作ろうとしているのですか?
それでSmartyが必要って??


0642nobodyさん2006/08/31(木) 18:17:23ID:fiP9snjq
>>638
良い事言ったな
0643nobodyさん2006/09/01(金) 00:34:31ID:???
>>639
いいですなぁ。
発注する側はフレームワーク使ってるからどうだっていうのは
ないので、なんでもかんでも、直さなきゃなりません。
0644nobodyさん2006/09/01(金) 01:24:18ID:???
使用しているオープンソースにおける他人のコードのバグだろうが、
要求仕様通りに動かなきゃ駄目でしょ。
これはPHPのバグですから、仕様通りに動きません、なんてのは通用しない。
0645nobodyさん2006/09/01(金) 02:16:37ID:???
>>644
そりゃそうだ。

> これはPHPのバグですから、仕様通りに動きません、なんてのは通用しない。

「じゃあJavaでもなんでもいいからやってください」と云われるだけだね。
しかも正論。

0646nobodyさん2006/09/01(金) 13:26:01ID:???
>>622
その発言は、フレームワークを理解していない。
だいたい、PEARで出来るのはPHPの関数組み合わせて出来るじゃん

>>630
禿同
0647nobodyさん2006/09/01(金) 16:40:15ID:???
むしろネタにマジレスしてるところがPHPユーザの（ｒｙ
0648nobodyさん2006/09/01(金) 16:52:41ID:???
すでに死語と化している＞ネタにマジレス
0649nobodyさん2006/09/01(金) 20:04:14ID:???
自作自演してるんだよ。ｶﾜｲｿｽ
0650nobodyさん2006/09/01(金) 21:58:13ID:???
>>648 ﾝﾅｺﾀｰﾅｲ
0651nobodyさん2006/09/01(金) 22:00:56ID:???
ZF＼(^o^)／ｵﾜﾀ
0652nobodyさん2006/09/01(金) 22:11:02ID:???
Mojavi ZF symfony cake どれが使い易い？　順番おしえて。
0653nobodyさん2006/09/01(金) 22:39:01ID:???
Mojavi…今さらナイ
ZF…未完成
symfony…遅い
cake…ソースが汚
0654nobodyさん2006/09/01(金) 22:43:58ID:???
扱い易いという点では、どれ順でしょうか？
0655nobodyさん2006/09/01(金) 22:45:49ID:???
Mojavi…枯れてはいる
ZF…ライブラリ集に近いので個別ですぐ使える
symfony…今のところ本命、Railsライク
cake…PHP4でsymfomyが使えないなら
0656nobodyさん2006/09/01(金) 22:45:56ID:???
Cakeじゃない？
0657nobodyさん2006/09/01(金) 23:04:34ID:???
symfony　cake　ZF　順なのかな？
Ethna Maple は、順番的にどうなんでしょうか？
0658nobodyさん2006/09/02(土) 00:19:02ID:???
>>657
etgnaはともかく、mapleはだめでしょ。
サポートが放置プレイだし。
0659nobodyさん2006/09/02(土) 00:24:05ID:???
素直にMojaviにしましょうか。
0660nobodyさん2006/09/02(土) 01:00:52ID:+E1W2ezn
じゃあ俺は素直にSimframe
0661nobodyさん2006/09/02(土) 01:01:07ID:???
Mapleは自分でソース呼んで、独自拡張やらバグフィックスするならいいよ
どうせ、公式なバージョンアップは期待できないし
0662nobodyさん2006/09/02(土) 01:10:42ID:???
>>660
久しぶりに名前を聞いて見てみたら結構進んでるね
速度は一番速いだろうから期待大
0663nobodyさん2006/09/02(土) 01:48:05ID:???
将来性を考えるとzend frameworkになると思うね。
PHPはフレームワーク内ですべてを完結してる分、開発停止になったときのリスクが大きい。
これがJavaやPerlならCPANのような標準ライブラリに依存してる部分があるから、フレームワークのコアだけ自分でメンテすればしのげるけど。
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の熟練度が低いのが多い
■ このスレッドは過去ログ倉庫に格納されています