【PHP】フレームワークについて語るスレ10【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/08/24(日) 21:43:37ID:???http://pc11.2ch.net/test/read.cgi/php/1202521438/
0052nobodyさん
2008/08/29(金) 01:39:13ID:???それは言えるかも。オブジェクト指向ではないと。
まあぶっちゃけstaticなプロパティを、globalsのいらないglobal変数として
使ってる私が通りますよ、と。
原則がないといくら文法がJavaに近くなっても意味がないってことはありそう
でもそれはデザインパターンと直接には関係しないような
singletonにしたって、普通にglobalじゃんっていう評価みたいだし。俺はよくわからんけどね
005323
2008/08/29(金) 03:15:53ID:???全部staticのクラスだろうがオブジェクト指向にすることは可能。
さらにいえば、別にクラスがなくても可能。
スレッドのないPHPではsingletonに色んなざっくばらんな代替方法があると。
ただ汎用的な知識としてはJavaのやり方が無難で
わざわざ他の方法をとることもないということだな。
よくわかった。
0054nobodyさん
2008/08/29(金) 03:25:48ID:???てかそんな投げやりなまとめなら23とか名乗らず名無しで書けよｗ
ちょっとでも擁護したレスが軒並み後悔するような、嫌な感じだｗｗｗ
さあ寝よ
0055nobodyさん
2008/08/29(金) 03:31:33ID:???別に君に擁護されなくても全く困らんよ？
もともと馬鹿に的外れな批判されても痛くもなんともないし
0056nobodyさん
2008/08/29(金) 09:09:19ID:EVgfNfndこんな説明をする先輩いるけど、ほんと自己満足だよな。
シングルトンのかわりにstaticメソッドでもいいじゃんというのは、そのとおり。
$obj = FooClass::getInstance();
$obj->method();
とするだけなら
FooClass::method();
でいいじゃんと思うのは自然なこと。
ただシングルトンはオブジェクト指向の機能を使えるので、
・継承が使える
・他のメソッドに引数として渡したりできる(オブジェクトなので)
・任意個の個数に設定できる(１個である必要はない)
という利点がある。こういった点が必要ないなら、staticメソッドで構わないよ。
たとえば
$obj = FooClass::getInstance();
other_function($obj);
ということをしたかったら、staticメソッドじゃなくてシングルトンのほうが自然だよね。
シングルトンもstaticメソッドもあくまで手段でしかないので、目的がstaticメソッドで満たせるなら
staticメソッドでもいいんじゃない。
0057nobodyさん
2008/08/29(金) 10:42:02ID:???クラス定義の中から、
class Hoge {
self::mixin('OtherClass');
}
↓
HogeにOtherClassがmixinされる
みたいな形にしたいのですが。
runkitは不安定だったので使いたくありません。
0058nobodyさん
2008/08/29(金) 10:51:30ID:???0059nobodyさん
2008/08/29(金) 11:13:07ID:YM8BIoOFRhacoというフレームワークではMix-inをサポートしているそうだからみてみるといいかも。
http://rhaco.org/
http://ll.jus.or.jp/2007/show/Event/Session/
> 変態的国産PHPフレームワークrhaco
> doctest、distutils、mix-in等PHPでは聞き慣れない機能について紹介します。
0060nobodyさん
2008/08/29(金) 11:39:37ID:???ありが㌧みてみます
とりあえずsymfonyのsfMixerを見てみたけど
__callの中からsfMixerを呼んで、そこでバックトレース情報を利用して
混ぜられた側のメソッドにデレゲートしてる感じ
この方法だと、混ぜられた側のメソッドから
混ぜてる側のメンバにアクセスできないような・・・
0061nobodyさん
2008/08/29(金) 12:35:23ID:???速度さえ気にしなければeval使えば大抵のことできますね～
evalでいくしかないかな
0062nobodyさん
2008/08/29(金) 13:15:34ID:???シングルトンパターンという実装パターンの一つとじゃ比較の対象にならない。
0063nobodyさん
2008/08/29(金) 13:57:50ID:???OOPは構造化プログラミングを含んでるんだよ
書き方の問題ではない
0064nobodyさん
2008/08/29(金) 19:54:55ID:YM8BIoOFなに難しいこといってんの？
シングルトンでやろうとしていることは、staticメソッドでもできるんじゃね？というだけの話。
なんで構造化プログラムだとかオブジェクト指向との比較とかでてくるの？ばかなの？
0065nobodyさん
2008/08/30(土) 03:25:30ID:???runkitは使ったことないですが、これは使ってます。
http://d.hatena.ne.jp/rsky/20080124/1201186473
qiqもすごくいい。もう普通のPHPは書けなくなるｗ
http://d.hatena.ne.jp/rsky/20080301/1204326365
0066nobodyさん
2008/08/30(土) 04:23:53ID:???あるプログラム、ある言語をを見て、それが構造化プログラミングなものなのか、オブジェクト指向プログラミングなのか、区別されるんだから。
その区別が出来ないというのは、人類皆兄弟とかいうたぐいの屁理屈だ。
0067nobodyさん
2008/08/30(土) 11:36:30ID:???自分を大きく見せようとする努力ほど無意味なものはない
0068nobodyさん
2008/08/30(土) 12:39:53ID:???プログラムを見て、オブジェクト指向プログラミング特有のクラス等を
（正しく）使っていればオブジェクト指向、使っていなければ構造化って判断をするな。
0069nobodyさん
2008/08/30(土) 18:14:35ID:OmTt4XZu昔の8ビットマイコン時代のBASICはGOTO文で処理を行き来する非構造化言語。
このプログラミングのパラダイムシフトは世界の共通認識だから。
0070nobodyさん
2008/08/30(土) 20:22:14ID:???「～判断をするな。」が、I do なのか you shouldn't do なのかわからん
>>69
>このプログラミングのパラダイムシフトは世界の共通認識だから。
だから、何なんだ
どうせならもう少し結論を明確にしてもいいんじゃないかと思う
話がふわふわして仕方がないｗ
0071nobodyさん
2008/08/30(土) 20:38:57ID:/jeGwvoC社内でWebサービス構築のために
MVCモデルのPHPフレームワークを作ることになったのですが、
どのあたりまでの実装でフレームワークとして体をなすのか分かりません。
どなたか教えていただけませんでしょうか？
0072nobodyさん
2008/08/30(土) 20:57:57ID:???既存のものを使った方がいいのでは？
0073nobodyさん
2008/08/30(土) 21:07:18ID:/jeGwvoC私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
0074nobodyさん
2008/08/30(土) 21:12:11ID:???オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）
>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど
だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？
極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
0075nobodyさん
2008/08/30(土) 21:29:08ID:/jeGwvoC>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。
実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
0076nobodyさん
2008/08/30(土) 21:46:18ID:???・各データの出し入れの基礎的な記述と、各データごとのロジック
・表示に関する基礎的な記述とロジック
を、実行スクリプトから切り離すのが最低限？
例えば、昔よく見た
<?php
// DB接続処理ほげほげ
（省略）
$sql = 'SELECT * FROM customer;';
$ret = mysql_query($sql, $db);
$rows = array();
while($row = mysql_fetch_assoc($ret)){ $rows[] = $row; }
?>
<html>
（略）
<?php
foreach($rows as $row){
（略）
}
?>
（略）
</html>
なんてのを、どう分けるか、何のために分けるか、というお話だと思うんだ。
その具体的な分け方・方向については・・・うーん俺は人に教えるほど
きちんと勉強していません。頑張れ！（ｵｲ）
0077nobodyさん
2008/08/30(土) 22:03:54ID:/jeGwvoCありがとうございます。参考にさせていただきます。
0079nobodyさん
2008/08/31(日) 18:59:51ID:???>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？
CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。
後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。
>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。
で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
0080nobodyさん
2008/08/31(日) 22:02:43ID:BcOgvLp9ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。
それにしても結構種類ありますよね～。
0081nobodyさん
2008/08/31(日) 22:18:42ID:???とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。
後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
0082nobodyさん
2008/08/31(日) 23:09:43ID:???他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし
ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
0083nobodyさん
2008/08/31(日) 23:44:28ID:BcOgvLp9なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。
>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。
ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
0084nobodyさん
2008/09/01(月) 07:50:32ID:???0085nobodyさん
2008/09/01(月) 16:27:37ID:???複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。
自作FWなんて最初からサポート止まってるも同然なんだけど。
あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
0086nobodyさん
2008/09/01(月) 20:42:35ID:???でも、フレームワークを勉強するためのコストが要るね。
でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
0087nobodyさん
2008/09/02(火) 15:46:31ID:???SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。
「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
0088nobodyさん
2008/09/02(火) 19:21:26ID:kKY94AaPデータベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
0089nobodyさん
2008/09/02(火) 20:08:08ID:???参照整合性制約（外部キー）までチェックしてデータ操作してくれる
モデルを実装しているフレームワークは寡聞にして聞いたことが無い。
有ったら俺も知りたいな。
0090nobodyさん
2008/09/02(火) 20:41:21ID:???0091nobodyさん
2008/09/02(火) 20:51:11ID:???DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?
0092nobodyさん
2008/09/09(火) 00:13:17ID:???0093nobodyさん
2008/09/13(土) 19:22:25ID:lKt9XZcpそしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ
0094nobodyさん
2008/09/13(土) 21:34:17ID:???例えば private と protected をわけるスタイルもある
_ と __ とか （←わかりにくいｗ）
Zendは特にわけてないのかな？
0095nobodyさん
2008/09/13(土) 22:06:52ID:???0096nobodyさん
2008/09/13(土) 22:09:06ID:???そんなに無いよ
0097nobodyさん
2008/09/13(土) 22:11:08ID:???せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ
0098nobodyさん
2008/09/13(土) 22:12:10ID:???0099nobodyさん
2008/09/13(土) 22:14:01ID:???コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは
__reserved_method_CONSTRUCT()
くらいやってくれてもなんの問題もないしな
0100nobodyさん
2008/09/13(土) 22:25:24ID:???.がいいよな.のほうがカッコいい
0102nobodyさん
2008/09/13(土) 22:35:44ID:???そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・
Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ
>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。
0103nobodyさん
2008/09/13(土) 22:53:57ID:???ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？
0104nobodyさん
2008/09/13(土) 22:59:30ID:???publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない
> protectedとprivateは別物なのに、
っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ
0105nobodyさん
2008/09/14(日) 00:28:45ID:???.のが使いやすいのは同意なんだけど、加算演算子と文字列連結演算子が別なのは
PHPの数少ない美点の一つだと思ってる。
0106nobodyさん
2008/09/14(日) 01:05:36ID:???それは単純にPerl由来なんだけどな。$ と同様に。
$ の使い方としては劣化してるし、この辺はもうPerl文化を切り捨てるか、
PHPの独自路線が欲しい所ではある
0107nobodyさん
2008/09/14(日) 01:09:29ID:???あれきもいし
0108nobodyさん
2008/09/14(日) 02:35:06ID:???Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。
あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw
0109nobodyさん
2008/09/14(日) 03:31:07ID:???0110nobodyさん
2008/09/14(日) 04:04:33ID:???４，５，６とか大変なんだが～
0111nobodyさん
2008/09/14(日) 04:10:29ID:???保守案件で4なら、ご苦労様としか言えぬｗ
6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ
0112nobodyさん
2008/09/14(日) 09:51:48ID:???0113nobodyさん
2008/09/14(日) 10:42:39ID:???0114nobodyさん
2008/09/14(日) 10:44:44ID:???0115nobodyさん
2008/09/14(日) 11:30:26ID:???0116nobodyさん
2008/09/14(日) 14:34:14ID:???0119nobodyさん
2008/09/17(水) 13:33:07ID:???・Ruby
・Python
・Perl
やっぱPythonかな？
0120nobodyさん
2008/09/17(水) 13:35:32ID:???0121nobodyさん
2008/09/17(水) 13:41:27ID:???仕事的には、PHPより高速で安定的に動作して、
月額1000円程度以上のレンサバには95%以上の確率で入ってるなら
なんでもいい。
そんなのある？
0122nobodyさん
2008/09/17(水) 13:43:47ID:???FastCGIの方は、95%にはちと足りんかな？ｗ
0123nobodyさん
2008/09/17(水) 13:50:56ID:???ZendStudioがあるから結局PHP使ってる・・
0124nobodyさん
2008/09/17(水) 18:12:51ID:???0125nobodyさん
2008/09/17(水) 18:45:58ID:???0126nobodyさん
2008/09/17(水) 22:00:15ID:???0127nobodyさん
2008/09/18(木) 02:36:03ID:???0128nobodyさん
2008/09/18(木) 16:41:27ID:???0129nobodyさん
2008/09/18(木) 16:49:43ID:???コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると
0130nobodyさん
2008/09/18(木) 16:52:54ID:???まだRubyで楽しんでる方が健全じゃねーかｗｗｗ
0131nobodyさん
2008/09/18(木) 19:11:26ID:???0132nobodyさん
2008/09/18(木) 19:12:59ID:ykJuPDO5別に、フレームワーク使ったってそのフレームワークに依存するじゃん
なんでQIQだと抵抗があるのか
0133nobodyさん
2008/09/18(木) 20:57:09ID:???調べて修正できるのかって点で、違いすぎるだろｗ
ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが
0134nobodyさん
2008/09/18(木) 21:38:02ID:???qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。
0135nobodyさん
2008/09/19(金) 00:57:48ID:???PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？ そりゃ失礼しました。
0137nobodyさん
2008/09/19(金) 12:02:16ID:???同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい
>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？
ひょっとして全部同列に見えるくらいのスーパーハカーですか？
0138nobodyさん
2008/09/19(金) 18:10:39ID:???サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方
0139nobodyさん
2008/09/20(土) 13:23:29ID:???qiqって何が素晴らしいの？
0140nobodyさん
2008/09/20(土) 13:42:12ID:???執着してる人が結構いるようだし
0141nobodyさん
2008/09/21(日) 05:27:57ID:???あと -> を . にすれば書くのも読むのも楽だ
0142nobodyさん
2008/09/21(日) 05:32:43ID:???0143nobodyさん
2008/09/21(日) 18:00:01ID:???>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか
おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。
PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
0144nobodyさん
2008/09/21(日) 19:43:02ID:???ライ・・ブラリ・・・？
> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ
0145nobodyさん
2008/09/21(日) 20:08:55ID:???0146nobodyさん
2008/09/21(日) 21:37:07ID:???単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw
それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。
0147nobodyさん
2008/09/22(月) 00:20:44ID:???>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。
0148nobodyさん
2008/09/22(月) 00:46:48ID:???0149nobodyさん
2008/09/22(月) 01:04:16ID:???ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。
0150nobodyさん
2008/09/22(月) 07:15:01ID:???0151nobodyさん
2008/09/22(月) 10:49:18ID:???0152nobodyさん
2008/09/22(月) 16:45:08ID:???思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？
class HogeController extends Controller
{
function index()
{
$data = $this->Model->classname->find();
$this->Component->classname->hogehoge();
}
}
■ このスレッドは過去ログ倉庫に格納されています