【PHP】フレームワークについて語るスレ13【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2009/03/24(火) 01:21:08ID:???●国外産●
symfony
ttp://www.symfony-project.com/
code igniter
ttp://codeigniter.com/
Zend Framework
ttp://framework.zend.com/manual/ja/index.html
CakePHP
ttp://www.cakephp.org/
Yii Framework ←New!! (Dec 03, 2008)
ttp://www.yiiframework.com/
●国産
ちいたん
ttp://php.cheetan.net/
Ethna
ttp://ethna.jp/
guesswork
ttp://classic.guesswork.jp/
maple
ttp://kunit.jp/maple/
●前スレ
【PHP】フレームワークについて語るスレ12【総合】
http://pc11.2ch.net/test/read.cgi/php/1229960175/
0511名無しさん＠そうだ選挙に行こう
2009/08/30(日) 16:08:56ID:???最終的には素のPHPで必要最小限の処理を手続き的に書くのが最速になる
この場合の「大規模」は、機能数や、エンジニア数（工数）という意味での「大規模」だと思う
0512名無しさん＠そうだ選挙に行こう
2009/08/30(日) 16:26:32ID:???0513名無しさん＠そうだ選挙に行こう
2009/08/30(日) 16:46:32ID:???0514名無しさん＠そうだ選挙に行こう
2009/08/30(日) 17:02:32ID:???0515nobodyさん
2009/08/30(日) 20:19:55ID:???いろいろ便利
0516nobodyさん
2009/08/30(日) 20:21:56ID:???もちろん探せば使えるところあるだろうけど、
PHPぐらいにたいてい対応しているレベルになるかなってこと。
0517nobodyさん
2009/08/30(日) 20:41:39ID:???0519nobodyさん
2009/08/30(日) 21:00:01ID:???0520nobodyさん
2009/08/30(日) 21:11:36ID:???0521nobodyさん
2009/08/30(日) 21:37:54ID:???0522509
2009/08/31(月) 00:45:30ID:???>>511
確かに「工数としての大規模」と「アクセスが大規模」の話がこんがらがってるね。
自分が言いたかったのは、前者の意味での大規模に、それほどの面白みを（個人的には）感じないという事。
でも、当然アクセス規模が（意図する・しないにかかわらず）大きくなるような案件には夢を感じる。
そういう時に、後からスケールアウトしやすく設計されているフレームワークを使っておくのはひとつの手だと思う。
最初からDBレプリケーションだのmemcacheだの利用した実装してアクセス全然だったらアチャーって思っちまうし。
話のポイント外してるようだったらごめん
0523nobodyさん
2009/08/31(月) 11:01:34ID:???俺俺フレームワークをかぶせるのがベストプラクティスだと思っている。
DBとかセッションとか普遍的なロジックはライブラリ集を使って、
認証やバリデーション、コントローラ/モデルあたりの毎回ロジックに改修が入る部分は、
自分の使いやすい方式で実装するのが良いと思う。
質問スレとかで、自分で書けば数行のものを、むりくりフレームワークを改修して実現しようとしている人を見ると微妙な気持ちになるわ。
0524nobodyさん
2009/08/31(月) 11:18:48ID:???はげしく同意。
フレームワークを使っても、毎回どっか改造しなきゃいけないところがあって、
なんかフレームワークを使ううまみがかなり減るよなーといつも思う。
0525nobodyさん
2009/08/31(月) 11:28:59ID:???けど他人が絡むのであれば、それではまずいだろう。
0526nobodyさん
2009/08/31(月) 11:39:25ID:???個々がフリーダムにコーディングしてしまうとまずいだろうが、
ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？
仮に特定のフレームワークを導入したとしても、連携とれるかどうかは別だしさ。
むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。
0527nobodyさん
2009/08/31(月) 11:49:57ID:???大抵、設定ファイルという名の新言語になっている。
0528nobodyさん
2009/08/31(月) 11:51:07ID:???>むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。
ほんとだよ
0529nobodyさん
2009/08/31(月) 12:36:19ID:???> ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？
であれば既存のフレームワークでいいのでは？
なぜ、車輪を再発明してまでFWを自作したい？
よっぽど特殊なドメインのWebシステムで無い限りはそんな必要性ないかと。
0530nobodyさん
2009/08/31(月) 12:51:53ID:???全部自分で作ってみたいんだよ。
フレームワークみたいなブラックボックスが我慢できないんだよ。
0531nobodyさん
2009/08/31(月) 14:23:01ID:???0532nobodyさん
2009/08/31(月) 14:33:19ID:???ハナから黙ってそれを使え。
0533nobodyさん
2009/08/31(月) 14:54:03ID:???結果的に使う人にとっては、同じようなFWになる気がするけど
自社だろうが、既存フレーワークだろうが使用するだけの人にとっては今まで出てきたような問題のメリットもある。
すでに十分な機能の自社フレームワークがあるならいいけど、既存のFWより機能の少ないものを作ってそんなにメリットあるのかな。
速度?でも色々付けたらそんな変わらないんじゃないの?
0535nobodyさん
2009/08/31(月) 15:06:09ID:???>であれば既存のフレームワークでいいのでは？
おまえさ、もうちょっと話の流れを追ってから書き込もうぜ。
526だけじゃなくて、もうちょっと上の523あたりから読んでみなよ。
既存のフレームワークに問題点を感じているから話がはじまったのに、
「既存のフレームワークでいいのでは？」とはこれいかに。
0536nobodyさん
2009/08/31(月) 15:48:00ID:???っていうか俺今までいろんなフレームワーク使ってきたことがあるが、
フレームワーク自体に手を入れなきゃいけなかったことなんて一度もないんだが。
単に、フレームワークを使いこなせていないだけなのでは？
0537nobodyさん
2009/08/31(月) 16:49:29ID:???大げさなラッパーコードを書かなきゃいけないのが不毛だって話だよね。
てゆーかどんなフレームワーク使ってても、
自然とそれを覆う為の俺俺フレームワーク(クラス群)が出来上がらないか？
>>536
フレームワーク自体は書き換えないだろ･･･
それを覆うコード群が膨大になると結局カオスになる。って事かと。
0538nobodyさん
2009/08/31(月) 16:57:10ID:???>>533
全てを再発明するわけでは無いよ。
既存フレームワークの設計上、実装が面倒になりそうな部分は、自前で書く方がメリットあるんじゃない？
既存フレームワーク ＋ 自作の使いやすいコンポーネント ＝ 俺俺フレームワーク
0539nobodyさん
2009/08/31(月) 17:00:43ID:???っていうのは同意
特殊なものを作ってるのかもしれないが
0540nobodyさん
2009/08/31(月) 17:20:51ID:???継承クラスや、ラッパーを作って使っている。
普通はするよ・・・ね？
0541nobodyさん
2009/08/31(月) 18:16:46ID:???0542nobodyさん
2009/08/31(月) 18:25:43ID:???1. FWなし
2. 100%俺俺FW
3. 100%一般的なFW
4. 一般的なFWの上に、俺俺FW
俺の場合、新しいプロジェクトを作るときは、たいていそれまでに作った
似たようなプロジェクトのコードをテンプレート代わりに使ったりするから、
上の分類だと4ということになるのか？
0545nobodyさん
2009/08/31(月) 20:37:26ID:???0547nobodyさん
2009/08/31(月) 21:01:44ID:???ラップするのは普通だし現実的だと思う
>>540が何でもかんでもとにかくラップするっていう話なら
ちょっと無駄な気はする。まあ、何でもかんでもってことは
さすがにないか
0548nobodyさん
2009/08/31(月) 21:22:25ID:???ありかなと個人的に思う。
学習についてはいろいろあるだろうけど、今まで作ってて結局周りを巻き込んで学習する時間なかったり
するもんで、php4とかで使用してたライブラリのコール仕様になるべく併せた形に書き換えて作ったことは何度かあった。
0549nobodyさん
2009/08/31(月) 21:53:21ID:???> 後からスケールアウトしやすく設計されているフレームワーク
実際、無いよなあｗ
だから、俺俺フレームワークでラップしてるような気がする。
開発者や開発案件の思想に依存する「俺俺スケール」が先にあるのかも知れない。
やってる事がbug-fixにとどまらず、俺俺部分に意志が入っちゃうんだよね。
>>542の分類で言うなら、
「一般的なFWの上に、俺俺bug-fixを加えただけのもの」
があってもいいはずなのに、なかなかそれだけで改造が終わることが無いｗ
0550nobodyさん
2009/09/01(火) 00:17:27ID:???差し迫った必要に迫られても、同じインターフェイスを持つ別のクラスを返すようにすればサクっと入れ替えられるしな。
まあ、DIなわけだが。
俺の場合、PDOのラッパークラスはかなり頻繁に作るな。フレームワークじゃなくて言語組み込みだからちとアレだが。
全メソッド呼び出しを記録できると色々便利。
0551nobodyさん
2009/09/01(火) 00:45:04ID:???0552nobodyさん
2009/09/01(火) 02:31:52ID:???＞ >>522
＞ > 後からスケールアウトしやすく設計されているフレームワーク
＞
＞ 実際、無いよなあｗ
＞
お前はFWを使いこなせてないだけ。
0554nobodyさん
2009/09/01(火) 08:56:29ID:???0556522
2009/09/01(火) 15:33:02ID:???レスありがとう
自分自身の感覚になってしまうけど、
CakeにしろSymfonyにしろ（この２つしか例に出せないゴメン）、
十分にスケールアウトを考慮した設計になってると思うよ。
でも逆に言えば、サーバ一台で完結させるような場合には、どうしてもオーバーヘッドが出て来るよね
むしろ本当に書き捨てでいいアプリならば、これらを使わずに
「俺俺」や「素のPHP」でもいいと思う。というかむしろそうする。
0557549
2009/09/02(水) 00:38:03ID:???ん？
俺は>>522読んで、（アクセス規模に対する）スケールアウトという言葉の用例が、
DBレプリケーションやmemcacheにかかってるんだと思ってた。
>>556
アクセス規模が増えてDBレプリケーションやmemcacheを使いたくなった時に、
Cakeやsymfonyだと簡単に移行できるかどうかって話だよね？
>>511と同じく、個人的にはそうは思えなかったけど、改めて調べてみると、
CakeではDBレプリケーション対応は簡単みたいだね。Propel13はダメだ（反論求む）
それに後付けのmemcache対応はどっちでも難しい。（反論求む）
sfSuperCacheも後付けで使うには設計を直す必要があるし（反論求む）
URIの変更もsfRouteやroutesだけの設定じゃ厳しい（ずれてる？）
0558nobodyさん
2009/09/02(水) 01:52:53ID:???0560nobodyさん
2009/09/02(水) 02:55:20ID:???0561nobodyさん
2009/09/02(水) 02:57:03ID:???そこがFWとして魅力を感じないよね・・
CakePHPのライブラリとして使うと結構その辺を補えるという話を聞くけど
0562nobodyさん
2009/09/02(水) 03:48:50ID:???dbの分散化対応は面倒くさいけど
0563nobodyさん
2009/09/02(水) 03:50:53ID:???たんに良くあるキャッシュコードでファイルに保存する代わりに
メモリに保存してるだけだろ？
0564nobodyさん
2009/09/02(水) 07:49:25ID:???ドイツ発のフレームワークってないし
0565nobodyさん
2009/09/02(水) 08:50:15ID:???0566nobodyさん
2009/09/02(水) 08:53:58ID:???0567nobodyさん
2009/09/02(水) 08:54:57ID:???0568nobodyさん
2009/09/02(水) 08:59:30ID:???0569549
2009/09/02(水) 11:30:11ID:???kwsk
>>562
DBレプリケーションも、それ前提で自作すりゃ簡単だろうさ。
memcacheもそうで、key-value型のホルダを先に作っておけば移行は容易。
でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
0570nobodyさん
2009/09/05(土) 05:37:36ID:HKGmqHHH日記サイトみたいなの作ってるんだけど
なんかJOINの結果が変。
他のDBに切り替えようと探してたらPosqlていうドライバ見つけた。
これけっこうｲｲｶﾓ。
SQLダンプからインポートして今のとこ順調。
0571nobodyさん
2009/09/05(土) 10:54:07ID:???>でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
>それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
>>562は、この点↑を含めて、既存のDBアクセス周りをラップする
クラスを作ればいいんじゃね？って言ってるんだと思うぞ
それに何でもかんでもmemcache頼みってのもどうかと思うぞ
DB周りのメモリチューニングとか、あるいはオンメモリDBを使うとか
その辺は検討したのか？
0572522
2009/09/05(土) 12:55:50ID:???> それに何でもかんでもmemcache頼みってのもどうかと思うぞ
ごめん、memcacheの話は自分が最初に振っちゃったので、
>>549 (>>569)関係ない。
自分は>>549 (>>557) 読んで、まあ確かに、config書き換えですぐに対応出来る訳ではないよなーと
思った。
0573nobodyさん
2009/09/05(土) 15:47:56ID:???フレームワークが出ても良いと思うんだ。
0575nobodyさん
2009/09/05(土) 17:08:00ID:???0576nobodyさん
2009/09/05(土) 17:51:14ID:???そういうこと。
キャッシュではなくモデルがkey-valueを基礎としているフレームワーク
O/Rつかってリレーショナルなデータをオブジェクトに変換するより
楽じゃないかと思うけどな。
ストレージとして、barkleyDBのようなkey-valueなデータベースだけじゃなく
ファイルやRDBにも格納できる設計で。
0577549
2009/09/06(日) 02:19:24ID:???> 既存のDBアクセス周りをラップするクラスを作ればいいんじゃね？
DBの結果セットをmemcachedに移行するというアプローチは、
自分でやった時はうまくいかなかったなあ。
結局、ご指摘の通りにオンメモリにして逃げちゃった。
なので、簡単に後付けで移行出来る方法があるなら良いなぁと思ったし、
無いんでないかなーと>>549で言っちゃった。
>>573-576
東京なんちゃら対応のなんちゃらモジュールがCakePHPで動くらしいね。
Cakeはよくよく調べてみるとみんなで結構何とかしちゃってる感がある。
0578nobodyさん
2009/09/06(日) 16:08:50ID:55qWNNESPerlは正直「使える」程度なんでPHPにしようと思うんだが、Pearを使わないでファイルコピーで設置完了することが可能なFWってあるかな？
一応SymfonyはSandbox使えば可能なのは知ってるが、流石に少々重たいかと思ってね。
・・・ま、「チャットごとき素のPHPで書けよ」ってのは御説ごもっともなんだがｗ、
どうもバリデータやHTML／SQLサニタイズを手で書くのは億劫になってね。
FWに慣れすぎたかもｗ
0579nobodyさん
2009/09/06(日) 16:39:56ID:???0580nobodyさん
2009/09/06(日) 16:53:37ID:???0582nobodyさん
2009/09/06(日) 17:02:52ID:???smarty(笑)
0583nobodyさん
2009/09/06(日) 17:13:23ID:???0585nobodyさん
2009/09/06(日) 17:53:04ID:???0586nobodyさん
2009/09/06(日) 17:53:38ID:???0587nobodyさん
2009/09/06(日) 20:33:41ID:???全部１クラスにまとめたようなレトロな作りにしても十分じゃね
FTPでアップロードして権限振ったらすぐ使えます、のほうがいいような相手なんでしょ
大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ
つか、578の場合レンタルでも探したほうがいいんじゃねｗ
そっちのほうが間違いなく多機能で安全で優れてるとおもうぞ
0588nobodyさん
2009/09/06(日) 20:54:55ID:???fitzgerald。本体が269行しかない。
ttp://www.moongift.jp/2009/06/fitzgerald/
バリデータは存在しないので自分で書かんといけないが。
一番面倒な、入力を一括してフィルタリングする機構はあるのでさほどの手間はない。
あと、エスケープ/サニタイズが面倒なのはお前が阿呆なだけ。
面倒ならエスケープしてからビューに渡す関数とか作れよ。
0589nobodyさん
2009/09/06(日) 21:47:35ID:???0590nobodyさん
2009/09/06(日) 22:56:49ID:???FWに慣れたっつーより、FWが無ければ何も出来ないの間違いじゃね？
正規表現とかもかけないんじゃね？ｗ
0591nobodyさん
2009/09/06(日) 23:09:44ID:???おめーも大差ないですよっと
0592nobodyさん
2009/09/06(日) 23:30:43ID:???0593nobodyさん
2009/09/06(日) 23:52:14ID:???0594nobodyさん
2009/09/06(日) 23:58:14ID:???0595nobodyさん
2009/09/07(月) 00:25:40ID:???0596nobodyさん
2009/09/07(月) 00:36:51ID:???0597nobodyさん
2009/09/07(月) 02:36:55ID:???PHPかどうかは関係無いし、PHPにも職人クラスのPGはいる。
ただ勘違いした「シロートさん」比率が、他の言語より圧倒的に多いｗｗ
0598nobodyさん
2009/09/07(月) 03:31:50ID:???0599nobodyさん
2009/09/07(月) 03:46:45ID:???0600nobodyさん
2009/09/07(月) 04:43:15ID:???で、上達するに連れ、言語仕様に不満が出てくる。
そして、他の言語へ移る。
Web用言語の登竜門みたいなもんだから、仕方ないべ。
今更Perlから入る人も少ないでしょうし。
グローバル関数をクラスライブラリ化して、型宣言もアリにして、
OO言語に生まれかわらんかな。
既存のグローバル関数で発生したエラーを例外処理化したライブラリはないかな?
0601nobodyさん
2009/09/07(月) 05:04:58ID:???登竜門としては Perl/CGI の方が良いと思うけどなぁ。
PHPから始めた人て、HTTP通信のバックエンドや、文字コードを理解して無い人が多いよね
multipartなPOSTデータをパースしたり、URLエンコード/デコードしたり、クッキーやセッションの仕組みを理解してなかったり、etc
バグが発生した時に、原因の切り分けが出来なくて困ってる人をよく見る。
0602nobodyさん
2009/09/07(月) 05:20:04ID:???俺はPHPからだったけどWebカメラいじりたくてソケットから弄りだした
まぁその前がC/C++だったから、文字列の扱いが超簡単で楽だったなぁ
0603nobodyさん
2009/09/07(月) 06:41:11ID:???0605nobodyさん
2009/09/07(月) 10:53:21ID:???0606nobodyさん
2009/09/07(月) 11:26:17ID:???確かにできたほうがいいけど、関数をあまり巨大化させなければそれほど問題にならないのでは？
PHPのだめな所はもっと他にあるだろ
0607nobodyさん
2009/09/07(月) 11:34:03ID:???ないかな、603は。
PHPだとそれらを別ファイル分けて書いて見通しだけは良くしても、結局includeだから同一ソース
ファイルに全部放り込んでるのと変わらん、データの独立性が…とか言いたいのかも。
まあ、クラス使えばいいと思うけど、そういうのは。
0608nobodyさん
2009/09/07(月) 11:42:30ID:???0609nobodyさん
2009/09/07(月) 12:08:07ID:???つまり糞がかけば糞になる程度がやや大きい。
その程度の話なんだが言語やOSの話になると痛いのがわんさか沸いてくる。
0610nobodyさん
2009/09/07(月) 18:10:57ID:???■ このスレッドは過去ログ倉庫に格納されています